Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115694
To: PHP Internals List <internals@lists.php.net>
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <CAOWwgpne5MEBxdvz=Q_zmRf=1abtQstMfpLXW4gbfp4+dRokfA@mail.gmail.com>
 <CA+kxMuQHz5U7D2E8gRyxxAfToJM6zc721qxLFcZFuTuiarVy3w@mail.gmail.com>
 <CAOWwgpkT2fLEEUgp40UrSMYmtPyoT2OAC_QUX4QDS5cXQAsBog@mail.gmail.com>
 <09e013c7-7104-82be-6711-41f74d9f1666@gmail.com>
 <CAOWwgpnJJT_XJG94fnCCOBN3RetspcFC8Pbzwx=89Z_T7Vh5og@mail.gmail.com>
Message-ID: <7ea8efdf-38b0-47d3-59b6-f6cb6665b284@gmail.com>
Date: Wed, 11 Aug 2021 14:31:10 +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: <CAOWwgpnJJT_XJG94fnCCOBN3RetspcFC8Pbzwx=89Z_T7Vh5og@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Re: [RFC] Nullable intersection types
From: rowan.collins@gmail.com (Rowan Tommins)

On 11/08/2021 13:09, Nicolas Grekas wrote:
>
>     On 10/08/2021 13:39, Nicolas Grekas wrote:
>     > I will wait if I don't have the choice, but as many others
>     reported, the
>     > experience with 7.0 missing nullability was a pain.
>
>     Apologies if you already did and I've forgotten, but could you please
>     expand on what "pain" you are referring to here?
>
>
> I personally did not experience that pain because I just skipped 7.0, 
> since it wouldn't allow expressing the nullable return types I had to 
> express in the APIs I maintain.


Sorry, I'm still confused what the "pain" is *other than* feeling 
obliged to wait until 7.1.


> The larger issue is that when used as a type on arguments, adding the 
> nullability flag isn't possible without a BC breaking change.


I can't imagine many people will force a parameter to be non-nullable 
just to use the shiny new syntax, then re-allow nulls in a subsequent 
version. More likely, they will leave that parameter un-checked until 
the full type can be specified.

There is also a lot of code out there which is either:

* in stand-alone applications, so backwards compatibility has no meaning
* in private libraries with a handful of uses, so bringing uses in line 
is trivial
* in public libraries, but marked "private" or "final", or documented as 
"internal use only", and therefore not subject to compatibility guarantees


> But until it's too late, I'm willing to engage in this topic because I 
> think the current state is far from ideal for 8.1.


There are always more features we could add, and there will always be a 
judgement call of what versions of PHP a code base should support.

If it was generally agreed that there was only one right way to 
implement nullable intersections, and it was a trivial change, then I'd 
support it as a "quick win"; but that doesn't seem to be the case.


Regards,

-- 
Rowan Tommins
[IMSoP]