Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115571
Message-ID: <43D8F75F-09B0-4AE4-A9EB-8775E231B367@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_390C94D7-3D82-48EB-BBE3-9B1BFD29D67E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Fri, 23 Jul 2021 21:42:49 -0700
In-Reply-To: <353F9140-7E59-4CD4-95D3-9BA8F9CA6C29@newclarity.net>
Cc: Nicolas Grekas <nicolas.grekas@gmail.com>,
 PHP Internals List <internals@lists.php.net>
To: Mike Schinkel <mike@newclarity.net>
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <353F9140-7E59-4CD4-95D3-9BA8F9CA6C29@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: tobias.nyholm@gmail.com (Tobias Nyholm)

--Apple-Mail=_390C94D7-3D82-48EB-BBE3-9B1BFD29D67E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> 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.

Yes of course. You cannot really do #1 without #2.=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

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

@Larry makes an argument to keep them:=20

> Requiring parenthesis now leaves the option open in the future to make =
them optional when doing full mixed types.


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)

> Given both of these sets of assertions I would ask the RFC's author =
and proponents what would be a worse outcome?

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

> 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


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>

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

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

Regards,
Tobias


> On 23 Jul 2021, at 20:53, Mike Schinkel <mike@newclarity.net> wrote:
>=20
>> On Jul 23, 2021, at 5:58 AM, Nicolas Grekas =
<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
>>=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


--Apple-Mail=_390C94D7-3D82-48EB-BBE3-9B1BFD29D67E--