Re: Pattern matching details questions

On Tue, Feb 4, 2025, at 22:16, Larry Garfield wrote: > On Tue, Feb 4, 2025, at 1:14 PM, Marc Bennewitz wrote: > > On 04.02.25 08:51, Rob Landers wrote: > >> > >> > >> On Tue, Feb 4, 2025, at 05:31, Larry Garfield wrote: > >>> Hi folks. Ilija is still working on the implementation for the pattern matching > >>> RFC, which we want to complete before proposing it officially in case we run into implementation > >>> challenges. > >>> > >>> Such as these, on which we'd like feedback on how to proceed. > > > >>> [1] > >>> https://github.com/Crell/php-rfcs/blob/master/pattern-matching/research.md > >>> > >>> -- > >>> Larry Garfield > >>> larry@garfieldtech.com > >>> > >> > >> Hey Larry, > >> > >> Instead of symbols, why not use words? > >> > >> We already have &&, but it looks like this uses & instead, which is a > >> bitwise-and. But the language does have “and” as a keyword. So instead of: > >> > >> $value is int & &$x > >> > >> It would be: > >> > >> $value is int and &$x > >> > >> Which removes the confusion you mentioned before (also for someone like me who uses > >> bitwise-and quite a bit). > >> > >> — Rob > > Patterns are deliberately designed as a superset of existing DNF types.. You can already have > a type of Foo&Bar, so we want the pattern for "instanceof Foo || instanceof Bar" to be > the same. That means & and | for conjunctions is necessary. Also supporting "and" > and "or" would technically be possible, but wouldn't resolve the issue (since & > would still be needed either way) and would just add more complication, confusion, and > inconsistency. I don't think that's viable. Interesting way of looking at it, not wrong either. I guess I'm not used to this syntax that much. It's like reading the following statement and working out what the value is without running it: add($a = add($a = 2, $a), $a = add($a, $a)) + $a; To me, mixing up both setting and using values in the same statement reads like above. Once you work out how it works, it makes sense that the first parameter is 4 and the second is 8, with $a == 8 and the result being 20 (https://3v4l.org/MPb5P). It takes some getting used to, though, and only works because we intrinsically understand the parser to AST to opcodes -- even if we don't know the details. Personally, it might be worth adding binding/setting values until a later RFC just to reduce the complexity until people get used to it. Right now, you (and maybe a couple of others) are probably the only people on earth who can truly understand how the syntax actually works; the rest of us may not _yet_ be equipped to give useful feedback. It won't stop me from trying to help, but I also don't want to waste your time by saying incredibly incorrect statements like using "and" instead of "&" to denote a type. :) — Rob