And I’m saying this is a pointless line to draw. Draw the line at, like, the lexer hack. Not this. If we had persisted with the “line in the sand” reasoning in Rust’s early days, we’d have been writing “match foo { None. => {…} }” because someone might name a variable None.
-
-
Yes, that was a mistake.
1 reply 0 retweets 5 likes -
Replying to @graydon_pub @pcwalton and
It was compounded by dozens of other "just a little more" mistakes and we are now in 2019 and nobody even knows whether it'll be possible to formalize the language in a grammar at all.
2 replies 0 retweets 5 likes -
You think that removing the dot from None was a mistake?
1 reply 0 retweets 1 like -
I don't remember if it was a leading dot or some other disambiguator at the time it was made ambiguous (we went through several), but yes.
1 reply 0 retweets 1 like -
Completely disagree. If the dot had stayed in, the language would have been much harder to learn. Hard to learn == a potential death sentence for Rust. With respect, I think we fundamentally value different things. I value pragmatism.
2 replies 0 retweets 3 likes -
You said the same thing about [] vs <> and there are many languages doing fine with both unambiguous constructors in patterns and square brackets for type params. With similar respect, I think you misperceived the cognitive costs of familiarity vs. simplicity on those.
2 replies 0 retweets 7 likes -
Square brackets don’t fix any ambiguities in Rust because of the conflict with array indexing. It certainly doesn’t solve turbofish. If we had gone with a.(index) for array indexing, *that* would have been a mistake.
4 replies 0 retweets 3 likes -
Replying to @pcwalton @graydon_pub and
I don't have Rust's whole grammar in my head, but with square brackets you'd at least have more similar grammatical roles in type and expr grammar, wouldn't
1 reply 0 retweets 0 likes -
It might mean that it's still semantically ambiguous at parse time but you could do a name lookup pass on the AST without needing turbofish or context-dependent parsing
1 reply 0 retweets 0 likes
Yeah, people floated the idea of a cover grammar, but unfortunately it doesn't work: https://github.com/varkor/rust/blob/b188c2a4eb7a3eede8477e3fbeaea623fc256586/src/test/ui/bastion-of-the-turbofish.rs … Square brackets for types might have allowed this to work, admittedly.
-
-
Actually, square brackets wouldn't have helped. e.g. foo[bar](baz) Can't resolve this based on scope either because "bar" could refer to both a type and a value in this scope.
2 replies 0 retweets 1 like -
Replying to @pcwalton @graydon_pub and
Ah, so Rust is a lisp-2, so to speak?
1 reply 0 retweets 0 likes - 1 more reply
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.