On Tue, 20 Jul 2021 at 14:41, Joe Watkins <krak...@gmail.com> wrote: > Agree, an RFC looks like the only way. > > This is not worth delaying a release for, nor is it worth postponing the > feature freeze date. > > It seems reasonable to fix this after freeze, would prefer to reach > consensus before RC stage. > > Cheers > Joe > > On Tue, 20 Jul 2021 at 13:07, Nikita Popov <nikita....@gmail.com> wrote: > >> On Mon, Jul 19, 2021 at 8:16 PM G. P. B. <george.bany...@gmail.com> >> wrote: >> >> > On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier < >> guilliam.xav...@gmail.com> >> > wrote: >> > >> > > On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas < >> nicolas.gre...@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 <dan...@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 >> > > >> > >> > Since when is usability for a specific project a consideration an RFC >> needs >> > to have? >> > If Symfony can't use it in its current state tough luck, >> > I'm sure plenty of other projects can, especially now that using 'new >> > Class' is possible as a default object value. >> > >> > I frankly don't care about being able to have some sort of partial union >> > possible with the usage of intersection types, >> > because it seems the machinery in the engine which makes null work, >> should >> > also allow any standard PHP types as those are part of a bitflag and >> > handling variance with them seems to work just fine... >> > >> > But for the love of god, this proposed syntax is horrendous, saying >> ?X&Y is >> > unambiguous is disingenuous. >> > It can either mean (?X)&Y = (X|null)&Y or ?(X&Y) = (X&Y)|null, the >> former >> > one being bogus as null&Y is an impossible type, something which should >> > error out to point out a potential bug in the same way we do for >> redundant >> > types that we know at compile time. >> > And if we allow this syntax then we really should be allowing ?A|B >> which is >> > dumb. >> > (and no ?X&Y is NOT something I consider forward compatible when it is >> just >> > going to become one more edge case we need to maintain because people >> have >> > no patience). >> > >> > If ?(X&Y) is allowed then ?(A|B) should also be allowed, and that needs >> an >> > RFC for sure due to the controversy it had in the union type RFC. >> > >> > The only remaining sensible choice is (X&Y)|null / null|(X&Y), but as I >> > said above if the machinery for null is there it must mean the machinery >> > for int/string/array/float/bool is also there, and frankly being able >> to do >> > something like (Traversable&Countable)|array is also extremely valuable, >> > maybe even more than nullability, but in any case this is going to be >> > confusing for end-users why only null (or standard PHP types) can be >> > combined in a union with intersection types. >> > >> > That's one reason why it's only pure intersection types, if I had more >> time >> > (or for crying out loud somebody would have paid me) to work on this I >> > would have loved to get full composite types working. >> > >> > And I find it frankly insulting that in the four month this RFC has been >> > published for discussion, with multiple push backs for voting due to >> bugs >> > and me wanting that people know what implementation is - for the most >> part >> > - going to land in php-src, this specific point has not been raised. >> > It just feels like you are pissing on 6+ months of *unpaid* work I did >> > because it doesn't suit your needs, and you just realised that and so >> > decided to throw a wrench into a carefully crafted RFC to "fix" it by >> using >> > a Twitter mob to put pressure on us/me. >> > >> > Maybe this topic didn't come up because for nearly everyone else "Pure >> > Intersection Types" means what it says on the can, moreso that in the >> RFC >> > the following line: >> > > 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 >> > makes it clear, and most voters also understood that '?' is not a type >> > "flag" but is syntactic sugar for 'null|'. >> > >> > There are plenty of issues with the implementation, from the whack >> parser >> > hack, the non support for static/parent/self, to the complexity of the >> > variance code, but I made all of those clear because they made *me* >> > uncomfortable with the implementation. >> > So if you are going to force this crappy syntax, then I'd rather axe >> this >> > feature completely (and nobody can use/play with it) then have >> something I >> > do not accept, nor are forced to accept because of a vote, land in core >> > making PHP even more of an inconsistent joke. >> > >> >> Hey George, >> >> I don't think there's been any malicious intent here -- it was obvious to >> you and I that not allowing unions implies not allowing nullability, but I >> can see how people less familiar with our type system implementation would >> not make that connection. After all, we do provide the separate ?T syntax, >> even if it is an internal alias for T|null. >> >> It's an unfortunate fact of the RFC process that concerns are sometimes >> only raised when voting starts and people start looking at the >> implementation -- or in this case, when they test the implementation after >> it has landed... >> >> In any case, I think it's pretty clear by now that there are some fairly >> strong opinions both on what the syntax for this should be (between ?X&Y, >> ?(X&Y), (X&Y)|null and X&Y|null, all of which have reasonable arguments >> for >> and against) and whether we should have this special case at all. I'm not >> sure we will be able to reach a sufficient consensus in this discussion. >> >> For that reason, I think this change should go through the RFC process. We >> can grant this an exemption from the feature freeze (as a clarification of >> an accepted proposal), but it should still go through the process. >> >> Regards, >> Nikita >> > If RMs and everyone else is okay for this being handled post feature freeze via an RFC, I am fine with it too.
Best regards George P. Banyard
