On 11-05-18 10:18 AM, Brendan Eich wrote:
I like type in front from C and C++, but it has caused huge mischief in the
lexers and parsers for those languages. Is it worth it?
People in this thread mentioned {x: uint, y: uint} vs. {uint x, uint y}, and it
does seem worth getting types-in-front in all contexts.
But the type-after-colon approach is strictly simpler to parse and make
optional. Can someone say why types-in-front wins? It's ok if it is an
aesthetic judgment by BDFL or cohort, I am mainly asking if I'm missing a
deeper reason.
I'm not sure how destructuring with TI affects this, so that could be exactly
what I'm missing. Thanks for any info.
As far as I know type-after-optional-colon wins on every
stated-or-explored technical merit (optional inference, destructuring,
symmetry with records) except two:
- You have to put in an extra character : when you want types,
maybe not a big deal when people use inference locally all the
time, but we always annotate fn signatures, so they get chattier.
- It's not what C, Java, C++, and the rest of that family does.
So .. I'm a bit torn. I'd go either way if there was really strong
consensus; as it stands I've hugged the security blanket of "because C
does it" here, for fear of scaring off all transitioning programmers.
On this point, at least, I'd welcome a straw poll. Just to figure
exactly how much everyone thinks "most programmers will balk" at "v:T"
rather than "T v". Look at these examples and decide:
fn push(&T[] v, T e) -> T[] {
let T[] u = v + [e];
ret u;
}
fn push(v: &T[], e: T) : T[] {
let u: T[] = v + [e];
ret u;
}
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
