Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115564
To: Nicolas Grekas <nicolas.grekas@gmail.com>, PHP Internals List
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Nullable intersection types
Thread-Index: AQHXf6lG17ahYHI3HkyKQ206do+j+6tQs7S/
Date: Fri, 23 Jul 2021 15:50:06 +0000
Message-ID:
 <BN7PR05MB4033B26F14CF1726EFFE810ADEE59@BN7PR05MB4033.namprd05.prod.outlook.com>
References:
 <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
In-Reply-To:
 <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [kNZw7Mo4V+xQq72geg6WUvsPUBtuKxNg]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cc78c5df-d3ff-4a44-534e-08d94df18ace
x-ms-traffictypediagnostic: BN8PR05MB6036:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 vrHUuvdY3r5thHyteZ63rUvKJPBnOzSCt3yUlgreKYv5ScletMp4O4DmIZvyENpL+d7uddI3Lwq/clMrPdedafWft1CWvt9BqKXJgrw85uDkDR9LeHWX/0F6lA78ETaQz0+c6qbSWHKE77yf4gwWRyMPdOD9AyB1wZ8iy+k4eFx9rOPaBS37UdqlIACSnaCdUedzRz9gS27q53qk+iOkjBR1cqoMv7jJos5Qw3Wd/9kLD9/4mSBDr9fsoUlhZUb5fOCm5gstchnYi42N8x/pm3f1cFr9dDVM//D5haMtQTCoRc//QMJn8UO9/UcR7L4Q7nZB6tSl6HGwM3azoLwkrtYHbFDX9JYGMjcWXlFGI6SQrxoN1Cqqsm2zW9hntuuOQ6IhWiQn5DdzVgtyoyJeyLZ0i33s7pAqtlz79JQXlgtkPIUZOzBvk/1rl1KFSH9OZKbPWZayqrCWI3IwIYYaR/fq+Z/MwQrUvVOTFyd3MeY=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 c2LIa4lqOTY1P2oYwuKWUB+8/Bo1oEZ73TiK/LSV/Rpv9fY0F1cPDR1MxAYAzrTeVe3g1idcDgkvFieY7kgdywHLr8VqHSn8gm5lY4FtVQVyKh6vNTdrggfcWl2nEhX9WtcptRxRXkecP/t8oPgVeg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR05MB4033.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: cc78c5df-d3ff-4a44-534e-08d94df18ace
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2021 15:50:06.0220
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR05MB6036
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: theodorejb@outlook.com (Theodore Brown)

On Friday, July 23, 2021 at 4:58 AM Nicolas Grekas <nicolas.grekas@gmail.co=
m> wrote:=0A=
=0A=
> Hi everyone,=0A=
>=0A=
> as proposed by Nikita and Joe, I'm submitting this late RFC for your=0A=
> consideration for inclusion in PHP 8.1. Intersection types as currently=
=0A=
> accepted are not nullable. This RFC proposes to make them so.=0A=
>=0A=
> I wrote everything down about the reasons why here:=0A=
> https://wiki.php.net/rfc/nullable_intersection_types=0A=
>=0A=
> Please have a look and let me know what you think.=0A=
=0A=
=0A=
Hi Nicolas,=0A=
=0A=
Thanks for your work on this. The RFC states:=0A=
=0A=
> the preference of the author of this RFC is to define =93?=94 as having=
=0A=
> a lower precedence than any other type-operator, and thus to use=0A=
> the =93?X&Y=94 syntax.=0A=
=0A=
I also strongly believe this would be a mistake. When union types=0A=
were introduced, it was explicitly decided not to use the `?(T1|T2)`=0A=
syntax, for the following reason [1]:=0A=
=0A=
> this notation is both rather awkward syntactically, and differs from=0A=
> the well-established `T1|T2|null` syntax used by phpdoc comments. The=0A=
> discussion feedback was overwhelmingly in favor of supporting the=0A=
> `T1|T2|null` notation.=0A=
=0A=
`?T` is a shorthand alias for `T|null`, and the alias cannot be used=0A=
to add `null` to a union type.=0A=
=0A=
Although PHP doesn't yet support generalized union and intersection=0A=
type combinations, this is almost certainly something we'll want to=0A=
enable in the future (in fact, this very RFC is a step towards this).=0A=
=0A=
But if union types don't support the shorthand nullability syntax,=0A=
and intersection types require it, how will the syntaxes be combined=0A=
in the future? E.g. will we write `null | A & B | C` or will it be=0A=
required to use something like `?A & B | C`?=0A=
=0A=
The latter is not only syntactically awkward but also very confusing.=0A=
=0A=
Since `|null` is the only supported syntax to add `null` to a union=0A=
type, for consistency the same syntax should be used to add `null` to=0A=
an intersection type. This will avoid confusion and inconsistency=0A=
down the road if a future RFC enables more general union and=0A=
intersection type combinations. It also avoids the need to define a=0A=
precedence for the `?` type operator.=0A=
=0A=
As you note in the RFC, PHP already defines `|` as having a lower =0A=
precedence than `&`, so `X & Y | null` can only be interpreted as=0A=
`(X & Y) | null`. This is consistent with other languages such as=0A=
TypeScript, where `A & B | C & D` is parsed as `(A & B) | (C & D)`.=0A=
[2]=0A=
=0A=
Since precedence is already defined for this syntax consistently with=0A=
other languages, I don't think it's necessary to require parentheses=0A=
if we use the `A & B | null` syntax.=0A=
=0A=
Best regards,  =0A=
Theodore=0A=
=0A=
=0A=
[1]: https://wiki.php.net/rfc/union_types_v2#nullable_union_types=0A=
[2]: https://github.com/Microsoft/TypeScript/pull/3622=0A=