`Option::<T>::None` vs `Option::None::<T>`

Are enum variants the only case against the rule of thumb that Type<T> becomes Type::<T> in path expressions?

Currently Option::<T>::None and Option::None::<T> seem to work identically, however Option::<T>::None looks "more correct" to me, even though Option::None::<T> can be simplified as None::<T> and there is no equivalent simplification of Option::<T>::None.

There is a very old post about this: Namespaced enums are weird in regard to generic paramters · Issue #22486 · rust-lang/rust · GitHub but it didn't tell the full story and was then closed. Someone please add the missing parts, e.g. RFCs, so we know how the grammar evolved to what it is today?

6 Likes

Interesting observation.

It sounds like an accident of history.

Notionally stabilized as part of RFC 2338 in Rust 1.37, but as noted in the summary, the Option::<T>::None syntax for non-aliases actually landed in Rust 1.33.

4 Likes

Thanks that's very good post. It's long so users may search

Alias::Variant::<TypeArgs> is not allowed but Alias::<TypeArgs>::Variant is

for the most relevant part.

Another relevant post

3 Likes