Do you think this syntax fares better for nested stuff than the same syntax in destructuring. I used to be really enthusiastic about pattern matching but am worried at how much people (myself included!) find nested destructuring inscrutable.
-
-
Replying to @wycats
Can you clarify? This is meant to be reeeeally close to how current JS destructuring works. The difference is some extra matching-related syntax. Guards exist exclusively at the toplevel.
2 replies 0 retweets 4 likes -
Replying to @maybekatz @wycats
I agree that deeply nested destructuring is a pain pretty much no matter what you do -- I think the utility of this is simplifying navigating 1- or 2-levels that often turn into `if` statements with stuff like `if (foo && http://foo.bar && foo.baz === 1)` etc
3 replies 0 retweets 7 likes -
Replying to @maybekatz @wycats
Using match, this would look like if (match (foo) { {bar, baz: 1} => true undefined => false }) Would be handy to have a `matches` keyword: if (foo matches {bar, baz: 1})
3 replies 1 retweet 12 likes -
My feeling is that pattern matching often allows you to do away with these if/then/else checks in the first place. Returning true/false for matches feels like an antipattern. Instead: match (foo) { {bar, baz: 1} => { doStuff() more() } _ => _ }
2 replies 0 retweets 5 likes -
Replying to @maybekatz @Vjeux
Rust has if-let, which is a combination of if and pattern matching, and it was a pretty early, very high-value feature (and I think morally equivalent)
1 reply 0 retweets 5 likes -
TLDR it's for the case where you want to write something like: match (expr) { { done: true, value: v } => (do something with v), _ => { /* noop */ } }
1 reply 0 retweets 3 likes -
I added a new section on potential future work that includes this (since I think there's enough meat to consider with this proposal as-is). Thanks for bringing it up! I actually think this is p great.https://github.com/zkat/proposal-pattern-matching/blob/master/README.md#if-match …
1 reply 0 retweets 1 like -
Replying to @maybekatz @Vjeux
Yeah it's most definitely not part of v1. But good to keep in mind as a constraint as we're tossing around syntax :)
1 reply 0 retweets 2 likes -
Replying to @wycats @maybekatz
By the way this proposal is different than mine. With matches the idea is to be an expression so that you can write if (a matches x && b matches y) but don’t want to capture variables. For context, I’m working on a new programming language and this was a very common pattern
1 reply 0 retweets 2 likes
A decent amount of use cases for if-let are really if matches. But sometimes you do want to capture variables, no?
-
-
-
Replying to @Vjeux @maybekatz
if-let serves double duty as matches infix but just today I hit a case in rust where a matches infix would have been nice as sugar.
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.