im v excited to be able to do thispic.twitter.com/B0IsL1OUhO
You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
I haven't run into that confusion myself, but it makes sense. Is it clearer when there's literals involves? (which is often the case w/ matching like this)
i.e. match (x) { {foo: 1} => ... } (vs {foo: bar})
Yeah it's clearer that way. The issue for me is stuff like: let { person: { name: n } } = contact; ^ it takes me some effort every time to remember that n is the variable being bound here.
I wonder if there's any way to address that. I can see how the : might make people think "variable-value-is: <val>". Because Language™
I think what we did in modules is pretty good but it came pretty late and we didn't retrofit destructuring: let { person: { name as n } } = contact For me, this is eminently more readable and clear, especially when syntax highlighted.
I periodically fantasize about bringing this up even now, because it has another use that's not covered by existing syntax: let { person: { first, last } as p } = contact For the case where you want the whole object and components
I'm proposing `var@123` in the bikeshed section, since that's what most pattern engines use.
Rust has `@` to the left and it's ... Ok (no pun intended). I think it's not ideal to reuse the @ sigil (inside a class, it'll become hard to pick out this syntax vs decorators). We could reuse sigils in diff contexts, but I tend to feel that we should try to avoid if possible.
As long as we have a way to do this kind of assignment, I'm cool with wherever the bikeshed goes. I still prefer @ for its terseness and how it allows plain matchers. I also suspect it's easier to read when you're binding a big obj ("everything after this" vs "everything before")
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.