Req #81268 [Ver]: intersection type incompatible with nullable props/returns

From: Date: Fri, 16 Jul 2021 15:44:32 +0000
Subject: Req #81268 [Ver]: intersection type incompatible with nullable props/returns
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-235097@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=81268&edit=1 ID: 81268 Updated by: girgias@php.net Reported by: nicolasgrekas@php.net Summary: intersection type incompatible with nullable props/returns Status: Verified 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: > 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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2021-07-16 15:28:06] girgias@php.net I addressed this on the PR (https://github.com/php/php-src/pull/6799#issuecomment-804793443), and I don't think we should accept it, it is super ambiguous ------------------------------------------------------------------------ [2021-07-16 15:25:55] nicolasgrekas@php.net Note that nullable intersection types are possible, here is one https://3v4l.org/aURFN/rfc#vgit.master $f = function (X&Y $foo = null) {}; $r = new ReflectionParameter($f, 0); var_dump($r->getType()->allowsNull()); Looking at the discussion at https://externals.io/message/113712, this was mostly overlooked. I think we should allow ?X&Y as property, return and parameter types. ------------------------------------------------------------------------ [2021-07-16 15:17:47] nicolasgrekas@php.net > this limitation is mentioned in the RFC Actual no, it's not. That's also why I opened the bug report, in case this was overlooked. Thanks for checking the error message, that's very much needed. ------------------------------------------------------------------------ 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

« previous php.bugs (#235097) next »