On 10-09-23 12:13 PM, Sebastian Sylvan wrote:
I'm sure you're already aware, but in case you're not, Haskell solves this
ambiguity by requiring that types and constructors start with an upper case
character, whereas everything else must start with a lower case character.
Yes, several languages do this; I'm not interested in using case
conventions to differentiate identifiers. It's too surprising to the
C-trained eyes, and besides there are several independent language rules
to look to for precedent (public/private, constructor/variable,
type/variable, module/type). I don't want to get into that game.
Or if you don't like that, you could always just use slot declaration syntax
to indicate that it's a slot and not a constructor (what you're doing is
related, after all, and saves a symbol):
Possible, but it doesn't really nest well, and will get clunky when
there are multiple bindings. Consider:
case (foo(auto x, bar(auto p, auto q), _)) { ... }
That's a lot of 'auto'. I'd prefer something lighter.
While we're bike-shedding, I'm not sure why the "auto" keyword is needed at
all.
Somewhat historical. We used to support a form of destructuring:
auto (x, y) = foo();
which would destructure the tuple returned from foo into a pair of
type-inferred slots x and y. Back then, tup(x,y) was spelled (x,y) as
well, and this had the undesirable influence of making type terms and
destructuring assignments ambiguous beyond single-token lookahead. A
design goal of the surface grammar (not articulated anywhere I suppose,
but I'll say so here) is to stick to single-token (or finite-token,
since "token" is a blurry concept) lookahead, LL(k) with minimal
disambiguation logic, that sort of thing. Be "well behaved". It's rude
to future tool-authors to pick a grammar that's too fussy to parse.
At the moment though, destructuring is long dead and the corresponding
ambiguity in the surface syntax is absent (I think), so you're probably
right, we can get away with single-token peek for ';' or '=' past the
first identifier following 'let', to decide if we're at the head of a
type term or a slot decl. But that may shift again. I'm happy to arrive
at that point eventually -- one less token! -- but for the time being I
don't feel a big rush to address it. There are a dozen such small
syntactic shifts on the table, but changing each will eat up a day I
could be spending on pushing rustc further towards working :)
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
