Re: intersection types and null for defaults, properties and return types

On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas <nicolas.grekas@gmail.com> wrote: > > https://github.com/php/php-src/pull/7259 > Great! Thanks! Interesting how it works out-of-the-box with just this addition in Zend/zend_language_parser.y: ```diff type_expr: type { $$ = $1; } | '?' type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; } | union_type { $$ = $1; } | intersection_type { $$ = $1; } + | '?' intersection_type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; } ; ``` On Mon, Jul 19, 2021 at 5:09 PM Dan Ackroyd <Danack@basereality.com> wrote: > nicolas-grekas wrote on the PR: > > ?X&Y cannot be confused with > > It confused me. A compiler might understand it, but as a human I have > trouble understanding it. > > Trowski wrote: > > The syntax should be either ?(X&Y) or (X&Y)|null > > Non-ambiguous syntax is much better than ambiguous syntax. > Maybe it's just a matter of habit? For instance I got used to seeing things like !$x = f() (e.g. `if (!$x = f()) { throw /*...*/; } /* use $x */`) because some CS consider explicit parentheses in !($x = f()) redundant (as PHP has a special case that "overrides" the normal precedence (!$x) = f() which would be an error). If you first consider X&Y as a type "unit", then it makes sense to make it "nullable" by prefixing it with ?, I think? > > But this discussion is moot for 8.1. > > This limitation might make intersection types not be considered usable > by some projects, but the feature freeze is today. > Which can also be reversed: "The feature freeze is today, but this limitation might make intersection types not be considered usable by some projects"? (playing devil's advocate, I don't master the process) Regards, -- Guilliam Xavier