Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115572
Message-ID: <94F0E6DA-8C69-402D-B6B2-5EBDEB6638FB@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B9CD5E51-1AE7-4BE1-8D39-0F25EEC1964F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Sat, 24 Jul 2021 01:01:58 -0400
In-Reply-To: <43D8F75F-09B0-4AE4-A9EB-8775E231B367@gmail.com>
Cc: Nicolas Grekas <nicolas.grekas@gmail.com>,
 PHP Internals List <internals@lists.php.net>
To: Tobias Nyholm <tobias.nyholm@gmail.com>
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <353F9140-7E59-4CD4-95D3-9BA8F9CA6C29@newclarity.net>
 <43D8F75F-09B0-4AE4-A9EB-8775E231B367@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_B9CD5E51-1AE7-4BE1-8D39-0F25EEC1964F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jul 24, 2021, at 12:42 AM, Tobias Nyholm <tobias.nyholm@gmail.com> =
wrote:
>=20
>> It seems this RFC is actually trying to accomplish two(2) things:
>>=20
>> 1. Add typehints for nullable intersection types to PHP.
>> 2. Get PHP to support a preferred syntax for type-hinting nullable =
intersection types.
>=20
> Yes of course. You cannot really do #1 without #2.=20
>=20
> I agree with Nicolas that `?X&Y` makes more sense. You add ? before =
the type. If the type is scalar, a class or an intersection type should =
not matter. But I hear some technical arguments from Derick so I won=E2=80=
=99t argue against that.=20
>=20
> Im fine with the syntax: `X & Y | null`
> I don=E2=80=99t think parentheses should be required. =46rom a =
mathematical perspective you want to add parentheses when you want to =
override the operation order. If you remove the parentheses and the =
expression has the same order of operations, then the parentheses is =
clearly not needed.=20
>=20
> @Larry makes an argument to keep them:=20
>=20
>> Requiring parenthesis now leaves the option open in the future to =
make them optional when doing full mixed types.
>=20
>=20
> I don=E2=80=99t understand why we should require something that is not =
needed simply because it would give us an option to remove it later=E2=80=A6=
 Could you elaborate why this is important? (Im probably missing =
something)

The difference is if we make the decision to use the `?X&Y` syntax and =
we later realize it was a mistake then we are stuck with it.=20

OTOH if we use the (X&Y)|null syntax and later realize it is okay to =
also allow `?X&Y` PHP could later be changed to allow it.

The later is the choice that manages future risk better.

>> Given both of these sets of assertions I would ask the RFC's author =
and proponents what would be a worse outcome?
>=20
> I don=E2=80=99t see how this question is relevant. We are not seeking =
compromises at the moment. We are seeking the best technical solution to =
a technical issue.=20

If you are not willing to compromise you will probably get nothing.

It is relevant because I was trying to get you to ask yourself if you =
would be happier if you get half of what you want rather than none of =
what you want. =20

Because there is a very real possibility you will get none of what you =
want if the RFC requires the syntax so many have objected to.

BTW, I do not have a strong opinion either way, but since I see than =
many do have a strong opinion I was trying to play arbitrator between =
two sets of people who each have very entrenched opinions where their =
opinions are in conflict.  If neither side will budge, nobody wins. =20

>> o, the entire discussion has claimed a "need" for nullable =
intersection types but AFAIIK they have been presented in completely =
abstract terms; i.e. no one has presented any real-world scenarios where =
they would actually use nullable intersection types. =20
>=20
>=20
> The =E2=80=9Cneed=E2=80=9D is covered by the discussion about PHP 7.0. =
See this post as an example: https://externals.io/message/115554#115563 =
<https://externals.io/message/115554#115563>
That message mentioned the need in abstract, but it did not provide any =
real-world examples.  It claims that there were real-world examples, but =
did not show any. =20

That message was also not part of the RFC.

Listen, I am trying to help make the RFC better to improve its chance of =
passing.  If you don't want that, then I will just demure.

-Mike

>=20
> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>=20
> When reading my message above could make it sound like I am =
pessimistic. That is not true. I am excited about this change and I am =
happy PHP has a long feature freeze so issues like this can show up =
before the release.=20
>=20
> Regards,
> Tobias
>=20
>=20
>> On 23 Jul 2021, at 20:53, Mike Schinkel <mike@newclarity.net =
<mailto:mike@newclarity.net>> wrote:
>>=20
>>> On Jul 23, 2021, at 5:58 AM, Nicolas Grekas =
<nicolas.grekas@gmail.com <mailto:nicolas.grekas@gmail.com>> wrote:
>>>=20
>>> Hi everyone,
>>>=20
>>> as proposed by Nikita and Joe, I'm submitting this late RFC for your
>>> consideration for inclusion in PHP 8.1. Intersection types as =
currently
>>> accepted are not nullable. This RFC proposes to make them so.
>>>=20
>>> I wrote everything down about the reasons why here:
>>> https://wiki.php.net/rfc/nullable_intersection_types =
<https://wiki.php.net/rfc/nullable_intersection_types>
>>>=20
>>> Please have a look and let me know what you think.
>>>=20
>>> Have a nice read,
>>>=20
>>> Nicolas
>>=20
>> It seems this RFC is actually trying to accomplish two(2) things:
>>=20
>> 1. Add typehints for nullable intersection types to PHP.
>> 2. Get PHP to support a preferred syntax for type-hinting nullable =
intersection types.
>>=20
>> Further:
>>=20
>> A. There seems to be consensus on the value of #1.
>> B. There seems to be consensus on using a syntax with parentheses for =
#1.=20
>> C. There is a lot of pushback on #2.
>> D. The desired syntax in #2 would reduce future flexibility, as Larry =
Garfield commented.=20
>>=20
>> Given both of these sets of assertions I would ask the RFC's author =
and proponents what would be a worse outcome?
>>=20
>> X. Getting typehints for nullable intersection types added to PHP, =
but not the desired syntax?
>> Y. Not getting typehints for nullable intersection types added to =
PHP?=20
>>=20
>> When answering please consider that #X is the outcome that would not =
preclude possibly getting #2 at a future date.
>>=20
>> ---------
>>=20
>> Also, the entire discussion has claimed a "need" for nullable =
intersection types but AFAIIK they have been presented in completely =
abstract terms; i.e. no one has presented any real-world scenarios where =
they would actually use nullable intersection types. =20
>>=20
>> It might be helpful =E2=80=94 or at least it would be for me =E2=80=94 =
if the RFC could add two or three real-world example use-cases where the =
author and proponents would actually like to use nullable intersection =
types in their future PHP code. =20
>>=20
>> #jmtcw
>>=20
>> -Mike
>=20


--Apple-Mail=_B9CD5E51-1AE7-4BE1-8D39-0F25EEC1964F--