Re: [RFC] Nullable intersection types

On Fri, Jul 23, 2021, at 11:06 AM, Pierre wrote: > 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. Requiring parenthesis now leaves the option open in the future to make them optional when doing full mixed types. Making them optional now requires that they be optional in the future when doing full mixed types. I vaguely recall there being some potential issue with making them optional for full mixed intersection/union types, but not the details. Either way, it's a not-small decision to make, and may have complicated implications for future work. It shouldn't be made on "eh, seems nicer" grounds in a post-freeze last minute RFC. Making it required now is the safer option, as it allows more flexibility in the future once someone tries to implement full union/intersection mixing. Making it optional later may still happen, I don't know, but it doesn't box us in to requiring it later. --Larry Garfield