Re: [RFC] Union Types v2

From: Date: Wed, 04 Sep 2019 11:54:31 +0000
Subject: Re: [RFC] Union Types v2
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-106851@lists.php.net to get a copy of this message
On Wed, 4 Sep 2019 at 10:59, Nicolas Grekas <nicolas.grekas+php@gmail.com> wrote: > we use "@return $this" quite often. On the implementation side, I'd > suggest enforcing this at compile time only (enforce all return points are > explicit, and written as "return $this" That's doing a deeper level of thing than a type system normal does. It's enforcing the internal behaviour of a function, rather than just defining the type of the parameter that is returned. > if we were to use "?int" instead, the engine would force the > community to add "return null;" That sounds like a bug to me. The fact that null is returned by any function that lacks an explicit return value, is well-defined, and one of the most underrated aspects of PHP imo. Arnold Daniels wrote: > Instead of using __toString as type maybe it's better to > introduce > a Stringable interface, Although casting things to string is probably the most common use case, if you're going to think about an RFC along those lines, covering all of the scalars would probably be a good idea, as that would allow people to use specific types for values, that can then be passed easily to functions that expect a scalar. function setRetryLimit(int $maxRetries) {...} class ImageUploadRetryLimit extends int {...} function processImage(ImageUploadRetryLimit $iurl, ....) { ... setRetryLimit($iurl); ... } That type* of stuff is completely possible currently in PHP, it's just that it's a bit painful to both write and read. cheers Dan Ack *intended

« previous php.internals (#106851) next »