Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115573
Message-ID: <B7C29E12-26AB-43BC-B945-95A33D4CF6A9@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0E5D1A8D-B571-4C85-A241-E5BED0500E69"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Fri, 23 Jul 2021 22:33:11 -0700
In-Reply-To: <94F0E6DA-8C69-402D-B6B2-5EBDEB6638FB@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>
 <43D8F75F-09B0-4AE4-A9EB-8775E231B367@gmail.com>
 <94F0E6DA-8C69-402D-B6B2-5EBDEB6638FB@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: tobias.nyholm@gmail.com (Tobias Nyholm)

--Apple-Mail=_0E5D1A8D-B571-4C85-A241-E5BED0500E69
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>> @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)
>=20
> 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
>=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.
>=20
> The later is the choice that manages future risk better.

I thought Larry was discussing `X & Y | null` vs `(X & Y) | null`.=20
I=E2=80=99ve dropped `?X&Y` because Derick had technical arguments =
against it.=20

The way I see it, there is no benefit in requiring the parentheses in =
`(X & Y) | null`. I suggest we use  `X & Y | null`.

>>> 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
>=20
> If you are not willing to compromise you will probably get nothing.
>=20
> 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
>=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.
>=20
> 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


That is a strange attitude. You are saying that you rather see a release =
with a know flaw than actually trying to find the best solution.=20
The release will be in 4 months. There is a process to clearly find =
issues like this. There is plenty of time to review this RFC and release =
it in beta 2 and let people test it. This is not a last minute thing, =
the process is designed for this.=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
>=20
> That message was also not part of the RFC.

The first paragraph under =E2=80=9CRational=E2=80=9D mentioned this: =
https://wiki.php.net/rfc/nullable_intersection_types#rationale =
<https://wiki.php.net/rfc/nullable_intersection_types#rationale>

In my world maintaining PHP libraries, it is obvious that 7.0 was =
missing this feature. As Benjamin mentioned, you could see that all =
libraries that migrated from 5.x just skipped 7.0 and went straight to =
support 7.1. I did the same for all my packages because of this reason. =
I made a misstake to assume that everybody had the same =E2=80=9Cworld =
of maintaining PHP libraries=E2=80=9D as I do.=20

So the =E2=80=9Creal world examples=E2=80=9D you are looking for is:=20
If we don=E2=80=99t merge a version of this RFC in 8.1, PHP packages =
will not take leverage of the inspection types until PHP 8.2. The reason =
for a package to drop PHP 7 support is to be able to use the cool =
features in PHP 8. This will require a major release (something all =
maintainer should do sparsely). Why would I do a new major release if I =
cannot properly define my API (interfaces)? I rather wait to next PHP =
version where I can express my API and do my major release then.=20

As the RFC states and Benjamin made extra clear, this is exactly what =
happened with PHP 7.0.=20

>=20
> 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.

>=20

Sorry if I sounded (or keep sounding negative). I appriciate you and =
everybody else participate in this discussion. We are all trying to make =
PHP better and we are all trying to move this RFC forward.=20

// Tobias


--Apple-Mail=_0E5D1A8D-B571-4C85-A241-E5BED0500E69--