Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115593
To: internals@lists.php.net
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <CAESVnVrCpYCB9VLFvAFbM4gzdBxHcmJQt75cqFcT0wHowMjXYw@mail.gmail.com>
 <F039E1EA-572D-460A-93B5-CBEAA47780FF@stitcher.io>
Message-ID: <27cb08f4-d557-1f53-eadf-132eed22c08d@gmail.com>
Date: Tue, 27 Jul 2021 16:03:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <F039E1EA-572D-460A-93B5-CBEAA47780FF@stitcher.io>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: rowan.collins@gmail.com (Rowan Tommins)

On 27/07/2021 14:32, Brent Roose wrote:
>  From a userland developer point of view:
>
> - PHP 7.0 types were a pain because of non-nullable types, the feature only became really useful as of PHP 7.1


You're not the only person to say this, but I find it really hard to 
believe.

If this was so urgent that the feature was "not really useful" without 
it, why did it take twelve years from the addition of type declarations 
in PHP 5.0 (for classes and interfaces) until the "?" notation in PHP 
7.1? Possibly because a syntax to make them nullable *was* added in PHP 
5.1 (SomeType $foo=null), which continued to work for all the types 
available in PHP 7.0. Or possibly because there were enough places where 
people wanted non-nullable parameters that the feature was useful even 
if it couldn't be used everywhere.

I can understand wanting to reduce the number of disruptive changes you 
make to the code base, but whatever version you pick, you can think of 
something in the next version up that you could wait for instead. Off 
the top of my head, you could set your minimum to...

* PHP 5.1, for the "array" type declaration
* PHP 5.4, for the "callable" type declaration
* PHP 7.0, for "int", "string", etc
* PHP 7.1, for the "?" nullable notation and "void"
* PHP 7.4, for typed properties
* PHP 8.0, for union types
* PHP 8.1, for pure intersection types
* PHP 8.2, for ... maybe mixed union-and-intersection, maybe type 
aliases, who knows...

Maybe 7.1 was a sweet spot for you in terms of cost-benefit; maybe 8.1 
won't be, but maybe it wouldn't be even with nullable intersections, and 
8.2 will be.



> Sidenote: weren't there any prior cases where an RFC was accepted only to have found out an oversight which resulted in that RFC to be postponed to the next release?


That's the opposite of what's being requested here - what's being 
requested is that an extra feature be added at the last minute, without 
any changes to the feature already agreed. To my knowledge nobody has so 
far suggested that the current implementation of intersection types 
should be removed until this is resolved, and I can't think of any 
reason why that would make sense.

Regards,

-- 
Rowan Tommins
[IMSoP]