Use parenthesis instead of angle brackets for generics

[dullbananas]

• Using parenthesis around the agruments for both generic types and funcions will add more consistency to the syntax.
• Unlike angle brackets, parenthesis don't conflict with comparison operators, so you can do Vec(Glyph)::new() instead of Vec::<Glyph>::new, which is:
  • less cluttered because :: is used less
  • less confusing because :: no longer has 2 meanings
• Using angle backets instead of parenthesis interferes with some behavior in code editors, such as wrapping and auto-closing parenthesis.

[Havvy]

This will not and can not happen.

The simplest reason why not is that this would be an extremely breaking change. Even if we switched over in editions, the vast majority of our documentation would have to be updated as well; something that is just not feasible.

Also, we still need the :: disambiguator because now we can't tell if it is a type generic or a function call which is worse. We would need type dependent parsing (like I think C++ does? don't quote me on this) and that's a mess.

---

To the people leaving negative emoji without giving any rationale: It looks like you're doing it in mean spirits. Please don't.

---

[dullbananas]

I just found out that <Foo<Bar>> can be used instead of Foo::<Bar>, which solves the problems about :: that I mentioned. This alternative syntax should be documented better, and the Foo::<Bar> syntax should be removed because it's redundant.

For generic functions, either the syntax described above should be allowed (e.g. <foo<Bar>>()), or the syntax for declaring generic functions should change from fn foo<T>() to fn foo::<T>() for better consistency.

[lebensterben]

less confusing because :: no longer has 2 meanings

:: is path separator and doesn't have two meanings.

[fanninpm]

the Foo::<Bar> syntax should be removed because it's redundant.

Good frend for Ferys sake forbeare,
to change the code encloased heare.
Bleste be y^e one y^t spares thes stones,
and cvrst be they y^t moves her bones.

[dullbananas]

:: is path separator and doesn't have two meanings.

:: is part of the turbofish syntax, which is completely different from paths

[lebensterben]

:: is part of the turbofish syntax, which is completely different from paths

that's wrong. :: is always path separator.

https://doc.rust-lang.org/reference/glossary.html?#turbofish

[Stargateur]

To the people leaving negative emoji without giving any rationale: It looks like you're doing it in mean spirits. Please don't.

@Havvy You can't know what people think, here you assume people intention, Argumentum ad hominem/Straw man (LUL), what you said here is bad. Please don't.

[dullbananas]

 👎😕👎
   \|/
    |
   / \

[SOF3]

I just found out that <Foo<Bar>> can be used instead of Foo::<Bar>, which solves the problems about :: that I mentioned. This alternative syntax should be documented better, and the Foo::<Bar> syntax should be removed because it's redundant.

For generic functions, either the syntax described above should be allowed (e.g. <foo<Bar>>()), or the syntax for declaring generic functions should change from fn foo<T>() to fn foo::<T>() for better consistency.

the turbofish syntax is still required for function calls.

mem::transmute::<Foo, Bar>(foo);

no way () or <transmute<>>` can replace this.

[jmaargh]

* Using angle backets instead of parenthesis interferes with some behavior in code editors, such as wrapping and auto-closing parenthesis.

If you're having trouble configuring your editor, try the asking in a community forum. I'm sure people will be happy to help. Otherwise if your editor's Rust support is buggy the place for the bug is with that editor (or its Rust plugin), not here.

Most editors should handle angle brackets just fine as they are common in many languages for generics (C++, Java, C#, etc.). The turbofish is more or less unique though, so I can see some editors might have bugs there.

[timleg002]

To me, the turbofish operator is confusing (but also cool, and a breath of something new). I'd prefer something like this: mem::transmute<Foo, Bar>(foo) (since it is a part of the function arguments). The :: having 2 meanings both as a path separator and part of the turbofish operator makes it confusing.

[thomcc]

I'd prefer something like this: mem::transmute<Foo, Bar>(foo)

This has been discussed, and was decided against. See https://github.com/rust-lang/rfcs/pull/2544 if you're interested in the discussion.