Document type_alias_enum_variants

[ehuss]

Stabilized in: https://github.com/rust-lang/rust/pull/61682 RFC (issue): https://github.com/rust-lang/rfcs/issues/2218 Issue: https://github.com/rust-lang/rust/issues/52118

~~There is a brief mention of this at the bottom of https://github.com/rust-lang-nursery/reference/blob/master/src/items/type-aliases.md that should be updated.~~
Example has been updated in #831.

@Centril were you planning to update this?

[Centril]

There is a brief mention of this at the bottom of https://github.com/rust-lang-nursery/reference/blob/master/src/items/type-aliases.md that should be updated.

I think this is the wrong place for the primary docs since it adds to the confusion around the misnomer that type_alias_enum_variants is. In other words, it is not about type aliases, but about type relative resolution to enum variants.

cc @eddyb @petrochenkov

What we should focus on is making sure the following is covered in some form:

Reference guide

In the value and type namespaces, type-relative resolution to an enum variant is permitted. This applies to expressions and patterns alike.

1. Type relative resolution

   • Let E denote an enum definition with variants V0 to Vn.

   • Let F denote a type expression normalizing to E with generic substitutions Si.

   • Then a path <F>::Vj may resolve, with highest priority, in the value and type namespaces, to the variant Vj.

2. Desugaring to type-relative resolution (pre-existing on stable)

   • Let X be an associated item of G.

   • A path G::X is equivalent to <G<..>>::X where .. denotes as many inference variables as G needs if it is generic.

   • A path G::<A0, .., An>::X is equivalent to <G::<A0, .., An>>::X.

Note that while resolution in the type namespace to an enum variant is allowed, enum variants themselves are not types (https://github.com/rust-lang/rfcs/pull/2593 would allow that).

[Centril]

@Centril were you planning to update this?

Yeah but it may take a while to get to... tho if someone wants to have a go at it that would be lovely.

[ehuss]

Since name resolution is not documented, I think it may be a bit difficult or awkward to define this in an adequate way. My intent was just that the clause at the bottom of that page is now wrong, it should be updated (or maybe removed if we don't want to have it there).

If you want, we can just remove the note and make this a sub-task of #568.

[Centril]

If you want, we can just remove the note and make this a sub-task of #568.

Yes this seems like a decent interim solution, but we should keep this issue open as a sub-task of #568 then.