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

Reply via email to