Document type_alias_enum_variants #631

Activity

1. ehuss

   added

   E-EasyWe believe this would not be difficult to actually fixWe believe this would not be difficult to actually fix

   on Jul 5, 2019
2. Centril

   added

   RFC Stabilization DocsDocumentation required for stabilizing a featureDocumentation required for stabilizing a feature

   EnhancementImprovement in a non-prose section of the bookImprovement in a non-prose section of the book

   on Jul 5, 2019
3. Centril commented on Jul 5, 2019

   

   Centril

   on Jul 5, 2019

   Last edited by Centril

   Contributor

   More actions

   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 (rust-lang/rfcs#2593 would allow that).
4. Centril commented on Jul 5, 2019

   

   Centril

   on Jul 5, 2019

   Contributor

   More actions

   @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.
5. ehuss

   added

   A-resolveName resolution, paths, namespaces, preludes, etc.Name resolution, paths, namespaces, preludes, etc.

   on Jul 5, 2019
6. ehuss commented on Jul 5, 2019

   

   ehuss

   on Jul 5, 2019

   ContributorAuthor

   More actions

   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.

   😄React with 😄1Reacted by Mazdak Farrokhzad
7. Centril commented on Jul 5, 2019

   

   Centril

   on Jul 5, 2019

   Contributor

   More actions

   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.
8. Havvy

   added

   New ContentMissing features or aspects of language not currently documented.Missing features or aspects of language not currently documented.

   and removed

   E-EasyWe believe this would not be difficult to actually fixWe believe this would not be difficult to actually fix

   EnhancementImprovement in a non-prose section of the bookImprovement in a non-prose section of the book

   on Jul 6, 2019