Edit report at https://bugs.php.net/bug.php?id=81268&edit=1
ID: 81268
Updated by: patrickallaert@php.net
Reported by: nicolasgrekas@php.net
Summary: intersection type incompatible with nullable
props/returns
-Status: Verified
+Status: Wont fix
Type: Feature/Change Request
Package: Scripting Engine problem
PHP Version: 8.1Git-2021-07-16 (Git)
Assigned To: girgias
Block user comment: N
Private report: N
New Comment:
The corresponding RFC (https://wiki.php.net/rfc/nullable_intersection_types) has been declined.
Closing the issue has there is nothing actionable nor a desire to implement it at this moment.
In the case of a new RFC, a bug entry isn't really relevant either.
Previous Comments:
------------------------------------------------------------------------
[2021-07-16 22:54:57] girgias@php.net
I'll reconsider it for £100000.
Any syntax proposition is going to be something which was deemed confusing, is either going to be an
edge case on its own, or would have lead people who voted for this RFC to vote against it (and I
know this for a fact).
Proper null-ability has only existed since 7.1, and I don't see why I should add something to
the language which is going to be inconsistent the moment we get composite type support, especially
when the complexity of the implementation comes from the variance checks, which would be rendered
even more complicated just to support this as an edge case instead of properly.
So no thank you.
------------------------------------------------------------------------
[2021-07-16 16:15:00] me at derrabus dot de
As mentioned on the PR already: https://github.com/php/php-src/pull/6799#issuecomment-805175050
I recognize the complexity of full composite types and I agree that we might not need them (yet).
But PHP has had nullable types long before it had unions. This feature has created the edge-case of
a type that cannot be expressed as nullable. I suspect that maintaining that edge case is more
complex than allowing nullablity again.
And if it's really just about the syntax for expressing nullability, I'm pretty convinced
that we can find a decent syntax for that.
Please reconsider allowing nullable intersection types.
------------------------------------------------------------------------
[2021-07-16 15:44:32] girgias@php.net
> This should be brought to php-internals IMHO.> The fact that "function (X&Y $foo = null) {};" works is going to be super useful.
I don't deny that, but the limitation that you cannot combine union types with intersection was
explicitly mentioned in the RFC. And a nullable type is a union type of T|null.
> But the fact that there is no type to express the type of the argument is WTF.
I agree that's a WTF, but that's an issue because of PHP's implicit nullable type,
which should die IMHO.
> It would be consistent to allow ?X&Y everywhere.
?X&Y for means (?X)&Y which is bogus/redundant, if we allow a nullable syntax it should be
?(X&Y) but this syntax was dropped from the union type RFC because many people opposed it
(https://wiki.php.net/rfc/union_types_v2#supported_types see Nullable Union types section)
So feel free to bring this up on php-internals, but I am *vehemently* against adding support for
nullable intersection types, and I consider the implicit nullable type behaviour a bug. Especially
that I have *no idea* if it follows LSP checks correctly as that was the *main* reason to not
support mixing unions and intersections in the first place.
------------------------------------------------------------------------
[2021-07-16 15:31:35] nicolasgrekas@php.net
This should be brought to php-internals IMHO.
The fact that "function (X&Y $foo = null) {};" works is going to be super useful.
But the fact that there is no type to express the type of the argument is WTF.
It would be consistent to allow ?X&Y everywhere.
------------------------------------------------------------------------
[2021-07-16 15:29:56] girgias@php.net
> https://3v4l.org/aURFN/rfc#vgit.master
I would consider that I bug in all honesty, because I forgot about PHP's peculiar implicit null
handling... which I have no clue if it works properly with variances checks
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=81268
--
Edit this bug report at https://bugs.php.net/bug.php?id=81268&edit=1