[rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[Daniel Trstenjak]

Dear rust devs,

is there a reason why it's e.g.:

   let vec = Vec::<int>::new();
   let vec = vec.iter().map(|i| *i + 1).collect::<Vec<int>>();

instead of:

   let vec = Vec<int>::new();
   let vec = vec.iter().map(|i| *i + 1).collect<Vec<int>>();


Thanks for any hints!


Greetings,
Daniel

Re: [rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[Steven Fackler]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

The syntax is ambiguous:

let foo = (HashMap<Foo, Bar>new());

is foo a HashMap<Foo, Bar>, or is it a tuple containing the results of
these two comparisons: HashMap < Foo and Bar > new()?

On Tue Nov 18 2014 at 1:38:26 PM Daniel Trstenjak <
daniel.trstenjak@gmail.com> wrote:

>
> Dear rust devs,
>
> is there a reason why it's e.g.:
>
>    let vec = Vec::<int>::new();
>    let vec = vec.iter().map(|i| *i + 1).collect::<Vec<int>>();
>
> instead of:
>
>    let vec = Vec<int>::new();
>    let vec = vec.iter().map(|i| *i + 1).collect<Vec<int>>();
>
>
> Thanks for any hints!
>
>
> Greetings,
> Daniel
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>

[-- Attachment #2: Type: text/html, Size: 1286 bytes --]

Re: [rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[Daniel Trstenjak]

Hi Steven,

On Tue, Nov 18, 2014 at 07:41:38PM +0000, Steven Fackler wrote:
> The syntax is ambiguous:
> 
> let foo = (HashMap<Foo, Bar>new());

You mean 'let foo = (HashMap<Foo, Bar>::new());' , right?

Is '::new()' a valid expression for accessing some kind of global
or super namespace? 

If not, then the expression doesn't seem to be ambiguous, but I can see,
that writing the parser would be more tedious.

So is this the reason, an easier parser implementation and therefore
most likely faster parsing of code?


Greetings,
Daniel

Re: [rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[Paul Stansifer]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

> If not, then the expression doesn't seem to be ambiguous, but I can see,
> that writing the parser would be more tedious.
>
> So is this the reason, an easier parser implementation and therefore
> most likely faster parsing of code?
>

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.

Paul

[-- Attachment #2: Type: text/html, Size: 805 bytes --]

Re: [rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[Tim Kuehn]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Tue, Nov 18, 2014 at 12:23 PM, Daniel Trstenjak <
daniel.trstenjak@gmail.com> wrote:

>
> Hi Steven,
>
> On Tue, Nov 18, 2014 at 07:41:38PM +0000, Steven Fackler wrote:
> > The syntax is ambiguous:
> >
> > let foo = (HashMap<Foo, Bar>new());
>
> You mean 'let foo = (HashMap<Foo, Bar>::new());' , right?
>
> Is '::new()' a valid expression for accessing some kind of global
> or super namespace?


Correct <http://is.gd/6T0U3R>; the `::` prefix resolves from the crate
root; unprefixed resolves from the module root.

[-- Attachment #2: Type: text/html, Size: 1013 bytes --]

Re: [rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[Daniel Trstenjak]

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.

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

Re: [rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?

[Matthieu Monrocq]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Wed, Nov 19, 2014 at 2:42 PM, Daniel Trstenjak <
daniel.trstenjak@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
>

[-- Attachment #2: Type: text/html, Size: 2453 bytes --]