Namespaced enums are weird in regard to generic paramters

[Kimundi]

Enum variants are namespaced now, but applying generic paramters to them in expressions still works as before, which means the correct way to type annotate a Option in a expression is to do this:

enum Option<T> {
    Some(T),
    None
}
let x = Option::Some::<u32>(1);

However, this is inconsistent with other namespaced constructs, like this:

struct Foo<T>(T);
impl<T> Foo<T> { fn new(t:T) -> Foo<T> { Foo(t) } }

let x = Foo::<u32>::new(1);

// With UFCS
let f = Option::<u32>::and as fn(Option<u32>, Option<u32>) -> Option<u32>;

Generally, type parameters of an item are supposed to go on that item in a path, but for enum variants this is not the case.

As a backward compatible solution to this, enum variants could be made to work similar to associated items of traits:

Option::Some      // Generic item fn<T>(T) -> Option<T>
Option::<T>::Some // Concrete instantiated item fn(T) -> Option<T>

[pnkfelix]

nominating for discussion at triage meeting. Sounds like there might be a 1.0 issue to address here.

[pnkfelix]

@alexcrichton points out that it is nice to write None::<T>

But it does seem like an inconsistency, i.e. a wart.

P-backcompat-lang, 1.0 beta, I-needs-decision.

[Kimundi]

Yeah, the ability to have None::<T> doesn't really need to go, but Option::<T>::None should also work for consistency... Tricky decision.

[nikomatsakis]

This is not clearly an inconsistency. It depends on how you view enums. In particular, at least under some of the "virtual struct" proposals, enums were kind of "shorthand" for something like:

abstract enum Option<T>;
enum Some<T> : Option<T>;
enum None<T> : Option<T>;

in which case the current behavior seems perfectly consistent.

[pnkfelix]

We are going to keep our current syntax/semantics, largely because we like being able to write e.g. None::<T>, and we are not convinced supporting a second way via Option::<T>::None is worth blocking 1.0 or 1.0 beta, and if there is a good argument for supporting it, we can add it backwards compatibly via the RFC process.

[U007D]

I just spent some time running into this issue. I agree it was the right decision not to block 1.0 on it, but does that mean the issue will never be addressed?

I think the turbofish syntax should also be supported for orthogonality, since it is not at all clear to new Rustaceans such as myself that an enum should be thought of differently.

[nikomatsakis]

I would be open to an RFC proposing a solution, but I don't think it's a priority for us on the lang-team -- happy to discuss it a bit though if you'd like to drive it! Maybe open a thread on internals?

[U007D]

@nikomatsakis I would love to land a feature (even a tiny one)!

Question: does it not being a priority for the lang team (understandable, given all the work going on) mean that even if we hash out a solution and I am able to implement it (neither being a given, you understand ;)) that it would still be unlikely to make it into the codebase?

Or does it simply mean the team has limited available cycles for hashing out the feature and implementing it themselves?

Thank you for the invitation, @nikomatsakis. 👍