Generics: Make enum variant syntax consistent with other types

[prasannavl]

Accessing generics in Rust roughly revolves around the below syntax today:

Item	Syntax
Type	T::<VARIANT>::Item
Method Calls	Function::<VARIANT>()
Enum	T::Item::<VARIANT>

While the first are second are fairly consistent, the enum one is weird and almost has an opposite syntax. The reasons mostly seem to be just historical for the inconsistency.

To illustrate it with an example:

let x = None::<i32>;             // OK
let x = Option::<i32>::None;     // Compiler error. (But this is the type syntax)

I think it would be nicer to allow a more consistent syntax, that allow enum to be work with the Type syntax as above.

Potential side-effects:

While bringing this up in the IRC, one of the nice folks pointed this very useful feature out - with the existing syntax, you can do use self::Enum::Variant; and then have Variant(foo) in the code. But this can easily be achieved with type aliasing, with the above syntax - making it even more consistent with other types.

While the existing syntax may or may not be deprecated at a later stage - I think adding a consistent syntax would be very useful.

[petrochenkov]

This is a sub-problem of other already accepted feature rust-lang/rust#26264.

[durka]

Both syntaxes could be allowed to fix the variant import issue (I don't see how type aliases address that). I agree it's confusing that Option::<i32>::None doesn't work.

[prasannavl]

@durka Variant imports can be done in a similar way that you'd import a generic type today, making the imports consistent too. (Basically, you don't import a variant directly, instead you achieve the same by importing the generic type and type aliasing it - just like every other type today).

use std::option::Option;
type MyOption = Option<MyType>;

[golddranks]

Here is another, although a different side of this consistency problem: You can define type aliases to types in a way that "statically curries" the type parameters. For example, you can define type MyResult<T> = std::result::Result<T, MyError>, and then use MyResult as a generic type that takes only one parameter. However, you can't curry functions in the same way, although they can be also generic, and they are statically known, and form their own unique types.

You can't define type rep = std::mem::replace<i32> or (IMO, another plausible syntax) fn rep = std::mem::replace<i32>.

Type aliases are for simplifying types. The same, of course could apply for functions, but they might have been lacking a sufficient demand for it. However, there is another implication that this kind of an extension would have: treating instantiations of generic functions as stand-alone items. This helps especially some macros, as the generic syntax might clobber them up, but "redefining" the generic as non-generic items prevents this problem.

[Pzixel]

Any progress on that? Accept/Reject/...?

[PvdBerg1998]

I have a large number of dynamically dispatched structs that are not object safe, therefore I use a gigantic enum. To run code on this, I need to use macro's. It seems to me that being able to have a function be generic over enum variants would solve this use case in a much cleaner way.