[RFC] Nullable intersection types View as Markdown

From the RFC: «Taking all these elements into account, the preference
of... and thus to use the "?X&Y" syntax».

I think this would be a mistake. You touch upon operator precedence, and
needing to know whether | or & is higher, and inventing a new precedence
for ?.

I would strongly advocate for not getting into the realm with any
operator precendence, but instead require parenthesis for any
combination. This gives the code reader and writer an immediate clue
about what the code does. Most coding standards also recommend this for
expressions in "if" statements and the like.

I do however agree with Sara's «over-delivering syntax that hasn't been
entirely thought through» point. It will take a lot longer to come up
with a proposal to combine intersection and union types.

That in combination that you're proposing this RFC after feature freeze,
while you've had four months to make this arguments as part of the "Pure
Intersection Types" RFC, I am currently not going to support this RFC
for inclusion into PHP 8.1.

cheers,
Derick

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

--

To unsubscribe, visit: https://www.php.net/unsub.php

These are precisely everything I think about this RFC. The only thing the
RFC made clear is why it is easy to make an exception for null while still
not providing a full mix of union and intersection.

Maybe my memory is also really bad, but the RFC makes it seem like version
7.0 was a mistake to be learned from which isn't clear for me. I understand
that introducing nullable intersection later will warrant a major version
and I don't see a problem with that. Pure Intersection RFC was such a
breeze vote precisely because it didn't involve the complexity of mixing
with union. Part of that complexity is now being rushed after feature
freeze.

As a maintainer of a large open source library, yes 7.0 was a problem due
to the nullability missing for return types and was the reason why a lot of
open source libraries jumped from minimum 5.4/5.5/5.6 directly to 7.1 to
avoid breaking BC twice for classes/interfaces when a signature of the
following kind was present:

/**

• @param string $foo
• @return ?string
  */
  function foo () { }

php 7.0: foo(string $foo) {}
php 7.1: foo(string $foo) : ?string {}

--
Marco Aurélio Deleu

Le 23/07/2021 à 17:56, Levi Morrison via internals a écrit :

As you note in the RFC, PHP already defines | as having a lower
precedence than &, so X & Y | null can only be interpreted as
(X & Y) | null. This is consistent with other languages such as
TypeScript, where A & B | C & D is parsed as (A & B) | (C & D).
[2]

Since precedence is already defined for this syntax consistently with
other languages, I don't think it's necessary to require parentheses
if we use the A & B | null syntax.
I want to acknowledge and reject this. Few people keep the bitwise
precedence information in their head. It's not worth it -- just
require parenthesis.

I don't want to reject this, this is actually a very good point, do not
reinvent a syntax that works somewhere else. And in the end, I do find
this readable. (I prey that people will use space in they types
definitions to make it even more readable, but style is not a topic for
this RFC.)

Accumulating union and sum types is probably not something I'd do every
day, so in the end, I'll probably always go and read the documentation
each and every time. But for people that do, they'll get used to it fast
enough I think.

This behavior seems fine, at least I think it's fine, as long as the
documentation is clear.

Regards,

--

Pierre

It seems this RFC is actually trying to accomplish two(2) things:

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.

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’t argue against that.

Im fine with the syntax: X & Y | null
I don’t think parentheses should be required. From 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.

@Larry makes an argument to keep them:

Requiring parenthesis now leaves the option open in the future to make them optional when doing full mixed types.

I don’t understand why we should require something that is not needed simply because it would give us an option to remove it later… 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.

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?

I don’t 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.

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.

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.

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.

The “need” 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.

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

——————

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.

Regards,
Tobias

Hi everyone,

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.

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

Please have a look and let me know what you think.

Have a nice read,

Nicolas

It seems this RFC is actually trying to accomplish two(2) things:

1. Add typehints for nullable intersection types to PHP.
2. Get PHP to support a preferred syntax for type-hinting nullable intersection types.

Further:

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.
C. There is a lot of pushback on #2.
D. The desired syntax in #2 would reduce future flexibility, as Larry Garfield commented.

Given both of these sets of assertions I would ask the RFC's author and proponents what would be a worse outcome?

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?

When answering please consider that #X is the outcome that would not preclude possibly getting #2 at a future date.

---

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.

It might be helpful — or at least it would be for me — 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.

#jmtcw

-Mike

I do not think this is strictly true. The issue that this RFC is running
into is that combination types between intersections and unions was
something that was avoided for the intersection types RFC. Not because the
authors never thought of it, but because the RFC would have become very
broad and encompassed many different discussions. But since the issue of
adding combination types only for null is now being presented, it seems
to me that a lot of people are taking the position that the syntax for it
should match what the future implementation of combination types is to
avoid confusion. I don't think that's an unreasonable position to take, and
the difficulty of that discussion perhaps illustrates why this wasn't
included in the original RFC.

We are not seeking compromises at the moment. We are seeking the best
technical solution to a technical issue.

But this presumes that the ONLY technical issue at hand is the ability to
have nullable intersections. Intersections are only available for class
types, you can't use intersections with scalars. The best technical
solution since there are no scalars is for people to use classes which have
a null state internally, or at least I could argue that's the case. (In
fact I did argue that's the case in a previous thread.)

I'm not even convinced that this is a technical issue at this point, so the
idea that there's no need for compromise is rather strange to me.

If the goal is to support nothing but nullable intersections, there's an
entire programming pattern1 to solve that concern. But as nulls have
always just "worked" for most PHP developers, I can see the argument for
it despite the fact that I think it promotes bad program design. I know
that I will use intersection types with the null object pattern in my own
libraries even if nullable intersection types are added.

So given that it's a special case of combination types, it makes sense that
people are at least discussing what combination types should look like
longer term.

I don’t understand why we should require something that is not needed
simply because it would give us an option to remove it later…

The point (I think) that Larry was making is that the parentheses can
always be made optional in the future, but if this is delivered without
parentheses now, it will be very, very hard to make parenthesis mandatory
later (BC break) if there is a reason to do so. What would that reason be?
I'm not sure, because a full implementation and RFC for combination types
hasn't been proposed yet

So requiring parentheses places the fewest restrictions on the anticipated
future RFC for combination types and allows the author to find the best
technical solution to that issue.

On Fri, Jul 23, 2021 at 9:43 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:

It seems this RFC is actually trying to accomplish two(2) things:

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.

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’t argue
against that.

Im fine with the syntax: X & Y | null
I don’t think parentheses should be required. From 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.

@Larry makes an argument to keep them:

Requiring parenthesis now leaves the option open in the future to make
them optional when doing full mixed types.

I don’t understand why we should require something that is not needed
simply because it would give us an option to remove it later… 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’t 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.

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.

The “need” 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>;

——————

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.

Regards,
Tobias

On Jul 23, 2021, at 5:58 AM, Nicolas Grekas nicolas.grekas@gmail.com
wrote:

Hi everyone,

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.

I wrote everything down about the reasons why here:
https://wiki.php.net/rfc/nullable_intersection_types

Please have a look and let me know what you think.

Have a nice read,

Nicolas

It seems this RFC is actually trying to accomplish two(2) things:

1. Add typehints for nullable intersection types to PHP.
2. Get PHP to support a preferred syntax for type-hinting nullable
   intersection types.

Further:

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.
C. There is a lot of pushback on #2.
D. The desired syntax in #2 would reduce future flexibility, as Larry
Garfield commented.

Given both of these sets of assertions I would ask the RFC's author and
proponents what would be a worse outcome?

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?

When answering please consider that #X is the outcome that would not
preclude possibly getting #2 at a future date.

---

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.

It might be helpful — or at least it would be for me — 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.

#jmtcw

-Mike

From a userland developer point of view:

• PHP 7.0 types were a pain because of non-nullable types, the feature only became really useful as of PHP 7.1

You're not the only person to say this, but I find it really hard to
believe.

If this was so urgent that the feature was "not really useful" without
it, why did it take twelve years from the addition of type declarations
in PHP 5.0 (for classes and interfaces) until the "?" notation in PHP
7.1? Possibly because a syntax to make them nullable was added in PHP
5.1 (SomeType $foo=null), which continued to work for all the types
available in PHP 7.0. Or possibly because there were enough places where
people wanted non-nullable parameters that the feature was useful even
if it couldn't be used everywhere.

I can understand wanting to reduce the number of disruptive changes you
make to the code base, but whatever version you pick, you can think of
something in the next version up that you could wait for instead. Off
the top of my head, you could set your minimum to...

• PHP 5.1, for the "array" type declaration
• PHP 5.4, for the "callable" type declaration
• PHP 7.0, for "int", "string", etc
• PHP 7.1, for the "?" nullable notation and "void"
• PHP 7.4, for typed properties
• PHP 8.0, for union types
• PHP 8.1, for pure intersection types
• PHP 8.2, for ... maybe mixed union-and-intersection, maybe type
  aliases, who knows...

Maybe 7.1 was a sweet spot for you in terms of cost-benefit; maybe 8.1
won't be, but maybe it wouldn't be even with nullable intersections, and
8.2 will be.

Sidenote: weren't there any prior cases where an RFC was accepted only to have found out an oversight which resulted in that RFC to be postponed to the next release?

That's the opposite of what's being requested here - what's being
requested is that an extra feature be added at the last minute, without
any changes to the feature already agreed. To my knowledge nobody has so
far suggested that the current implementation of intersection types
should be removed until this is resolved, and I can't think of any
reason why that would make sense.

Regards,

--
Rowan Tommins
[IMSoP]

• PHP 7.0 types were a pain because of non-nullable types, the feature
  only became really useful as of PHP 7.1

See, this keeps being said, but as another userland developer it's
extremely confusing. The types in 7.0 were very useful, and I personally
didn't notice at all that they were missing because I used something like
function(int $var = null), which is how nulls had been marked before PHP 7.

In fact, when 7.1 was released, none of the signatures changed in my code,
they were just updated to a different syntax.

• I share many people's opinion that this falls in the category of
  oversight

I don't see how, when the intersection types RFC was:

• Named "pure intersection types", which to me can only mean that the
  authors were both aware that there were other integrations which may be
  suggested and were excluding them from scope.
• It contained an explicit mention of this issue:

This means it would not be possible to mix intersection and union types
together such as A&B|C, this is left as a future scope.

I also am not seeing that opinion from "many people" in this thread. Are
you referring to other people off-list who are discussing this?

Jordan

Hi all

From a userland developer point of view:

• PHP 7.0 types were a pain because of non-nullable types, the feature
  only became really useful as of PHP 7.1
• I share many people's opinion that this falls in the category of
  oversight
• I think (A&B)|null is the only sensible way to go

Sidenote: weren't there any prior cases where an RFC was accepted only to
have found out an oversight which resulted in that RFC to be postponed to
the next release?

Kind regards
Brent

On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas &lt;nicolas.grekas@gmail.com

wrote:

https://wiki.php.net/rfc/nullable_intersection_types

I've commented on the PR and in R11 a bit already, but I'd like to state
my
position here for the record. I do see the value in having nullability,
but I can't disagree enough with the ?X&Y syntax no matter how
technically right the argument about operator precedence is. Even
ignoring
that literally nobody carries around a complete operator precedence table
in their head, we simply can't predict how making this decision now will
impact future plans for combined intersection/union types. The same
argument honestly goes for every other syntax proposed, including
(X&Y)|null which is also prone to making things worse.

Nullable intersection types IS an implementation of combined
intersection/union types, even if a narrow one. Those have not been
planned
out or approved, and they're too broad to sneak in post feature freeze.
Period. Let's take the coming months to flesh out the edge cases on
combined types. Let's maybe even look into type aliasing, which may have
the side effect of making combined types more readable (or maybe less,
who
knows!).

Most importantly, let's accept the fact that PHP's release cycle is only
12
months and we had pandemics that lasted longer than that. Next year is
right around the corner.

TL;DR - I've decided my vote.

-Sara

--

To unsubscribe, visit: https://www.php.net/unsub.php

On Wed, 28 Jul 2021 at 08:29, Nicolas Grekas nicolas.grekas@gmail.com
wrote:

Nullability is a special beast in PHP. We have a range of operators
dedicated to it. That's also why I think it deserves special care, and
why
I think it's important to have this discussion before 8.1 is out.

Why does this change need to be done now, rather than wait for 8.2?

I can't see a clear reason in the RFC and saying 'nullability is
special' doesn't seem a clear reason either. If you think you'll only
be able to use intersection types when they can be union'ed with null,
then ... just wait until they are?

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. We can learn from past
mistakes. In my opinion, we can do better than the "wait for 8.2" stance
I'm hearing around and make intersection nullable - like every other type
in PHP - right now while we first release it.

More generally, I'm not in favor of shipping partial features based on
hypothetical future improvements. We don't know the future. Eg type
aliasing or generics are vaporware right now. One or both of them might
never happen, for whatever reason.

Andreas Leathley wrote:

Having one clear RFC voting option (with no
secondary syntax voting option) also seems the most honest, as if
somebody agrees that nullability would be useful but would only accept
one syntax choice, that seems impossible to represent, necessitating a
no vote on the whole RFC.

I strongly agree with this.

Having a situation where people will want to change their primary
vote, based on which option in a secondary vote is winning is a "not
good" situation.

Having syntax for a type system be chosen by a popularity contest,
where many of the voters are not aware of the implications of the
choices is also not good.

I find it quite dismissing to refer to "voters" as a group that decides by
"popularity contest" or that is "not aware of the implications of the
choices". I do trust the voting process and I do think that the discussions
we're having here on php-internals and related media are appropriate means
to raise voters' awareness of the topics at a glance (I also think the
voting process might be improved, but there's already a separate thread
about that.) Instead of fearing others, let's discuss things and ensure we
raised all points so that ppl can make an informed decision.

After this discussion, I hope ppl will vote according to what they think is
best for PHP as a whole, all questions included, and independently from the
rest. That'd be the most honest thing to do IMHO, and the best for PHP (on
this RFC or on any other.)

RFC authors should be trying to pass an RFC they are sure is the right

choice, not leaving important decisions up in the air.

Because nobody raised any potential blocker with any of the proposed
syntax, I'm confident that all voting options have equal future-proofness.
The remaining is a matter of coding style preference. While as the author
of the RFC I do have a preference for the "?" nullability flag, others have
strong and different opinions about it. Since the primary motivation for
this PR is to provide nullability for intersection types, I'll be fine with
any syntax that is consensual eventually.

Larry Garfield wrote:

Some other mechanism such as the sometimes discussed type
aliases provides an alternate way to solve this problem.

This is an important point and why trying to push changes to the type
system through after feature freeze is a bad idea.

The example in the RFC uses single letter class names; in my
experience most classes have quite a few more letters in them than
that. Trying to use intersection types with realistic class names
leads to code like this, for a custom cache definition*.

function foo(Get|GetOrDefault|Set|SetWithTTL|GetOrGenerate|Clear $cache) {
...
}

Which is pretty unreadable. I don't think I'll be using intersection
types much until PHP has the capability to compose types. e.g.
something similar to this:

type SimpleCache = Get|GetOrDefault|Set|SetWithTTL|GetOrGenerate|Clear;

function foo(SimpleCache $cache) {
...
}

At which point the need for being able to include nullability in the
intersection type goes away. You can instead use the existing ability
to indicate a type can be null:

function foo(?SimpleCache $cache) {
...
}

That's an excellent argument in favor of using "?" actually (syntax
consistency and readability), thanks for pointing it out. I'd go as far as
saying that type aliases should forbid making "null" part of them. That
way, nullability would always be explicit in the local type, with an
easy-to-spot nullability flag.

So yeah....I agree that widespread adoption of intersection types

might not happen in 8.1 but that's fine, and better than possibly
implementing the wrong thing after feature freeze.

We're having this discussion to be sure that "wrong" won't happen, while
the good will.
And based on what was raised so far, I see only the good coming.

Cheers,
Nicolas