On Wed, Nov 19, 2014 at 2:42 PM, Daniel Trstenjak < daniel.trsten...@gmail.com> wrote:
> > Hi Paul, > > On Tue, Nov 18, 2014 at 03:31:17PM -0500, Paul Stansifer wrote: > > It's not so much the speed of the parser that is the matter, but the > fragility > > of the grammar. The less lookahead that's required, the more likely it > is that > > parser error messages will make sense, and the less likely that a future > change > > to Rust's syntax will introduce an ambiguity. > > Ok, that's absolutely reasonable. > > I'm wondering, if it could get distinct by enforcing some properties > which are already compile warnings, that types should always start > with an upper case and functions/methods with a lower case. > Note, the syntax also applies to functions; ie if you have `fn pow<T: Num>(T n, uint e) -> T` then to qualify `T` you can use `pow::<int>(123, 4)`. Therefore using case would not solve the issue (not completely, at least). > > let foo = (HashMap<Foo, Bar>::new()); > > But then 'HashMap' could still e.g. be an enum value instead of > a type, but currently you certainly also need some kind of context > to distinguish cases like e.g. 'some(x)' and 'Some(x)'. > > > Somehow I think, that's a very good idea to enforce these > properties, regardless of the issue here. > > If you've read code where everything starts with a lower case or > upper case (even variables!), then you can really see the value > of using the case to distinguish types/functions/methods. > > > Greetings, > Daniel > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev