On Tue, Feb 4, 2025, at 4:30 PM, Rob Landers wrote: > On Tue, Feb 4, 2025, at 22:16, Larry Garfield wrote:
>> 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: Well, right now no one is used to it. :-) Unless they've spent a lot of time in Rust. Ilija and I have been staring at it longer than anyone else, obviously, but any new feature is, well, new. > 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. That's been suggested a few times. The challenge here is: 1. variable binding is a core part of pattern matching in basically every language that has it. The decomposition capability is the primary use case. So leaving that out gives us... basically a more compact way to chain instanceof, which isn't that impressive. 2. Variable pinning is an optional feature, most languages don't have it, but it's a nice-to-have. It would be fine to punt to later. 3. Except we really need to ensure that the syntax for variable binding doesn't cause problems for a future variable pinning feature due to syntax/parsing confusion. That means we have to do at least a large chunk of the design and trial implementation up-front to make sure we're not painting ourselves into a corner. 4. At which point, we've basically implemented pinning anyway so may as well just include it. --Larry Garfield
