Type alias enum variants #2338

djc · 2018-02-15T19:19:27Z

This RFC proposes to allow access to enum variants through type aliases. This enables better abstraction/information hiding by encapsulating enums in aliases without having to create another enum type and requiring the conversion from and into the "alias" enum.

WiSaGaN · 2018-02-19T06:58:47Z

I have run into this in my projects several times. Fortunately, I have access to the original type definition, so I could add a "constructor" from variant to work around this. The absence of this functionality came as a surprise to me, although it is not a bug in a sense. Implementing this would reduce the frustration people experience when initially they implicitly thought it would work, but later found out it would not.

Another question is how close this relates to using alias to construct unit and tuple. From a usage point of view, they are the same surprising unsupported functionality of alias. Do they differ a lot inside the compiler? Should we discuss both or it requires another RFC?

At last, how much inconsistency would an implementation bring to the compiler if we must introduce them?

djc · 2018-02-19T08:17:17Z

@WiSaGaN thanks for the feedback. I don't know much about the compiler internals, but I would guess the aliasing of unit and tuple types would not be very tied up in the enum variant handling, so I think it would make more sense to handle that in a different RFC. It would make sense to me, though, for much of the same reasons that I wrote up in this RFC.

petrochenkov · 2018-02-21T19:48:50Z

Tracking issue for this feature - rust-lang/rust#26264.
It was previously considered not requiring an RFC, just implementation.

petrochenkov · 2018-02-21T20:14:03Z

The previous (very much reasonable) decision in rust-lang/rust#26264 was to resolve variants exactly like inherent associated items - variants themselves as associated types and their constructors as associated values.
So it would be useful to compare passing generic arguments to both of them.

Ty<Args1>::AssocItem<Args2> or Trait<Args1>::AssocItem<Args2> means that Args1 are passed to the parent item and Args2 are passed to the associated item.
No argument transfer between segments happen, arguments are always passed to their proper segment.

For variants that would mean EnumAlias<Args1>::Variant and Enum<Args1>::Variant being the correct way pass generic arguments (variants don't have their own generic parameters (yet) so nothing is passed to them).

Enum::Variant<Args1> being legal and meaning Enum<Args1>::Variant exists for historical reasons and is, IMO, a wart. We should not extend it on type aliases (but we should keep it for backward compatibility of course). More details in https://internals.rust-lang.org/t/pre-rfc-enum-variants-through-type-aliases/6433/5.
So, I think we should go the EnumAlias<Args1>::Variant way instead of the scheme proposed in the RFC.

djc · 2018-02-22T18:29:17Z

I agree with @petrochenkov that Enum<Arg>::Variant makes more sense in principle than Enum::Variant<Arg>. However, I don't think the interactions with the proposed change in this RFC are such that it makes sense to start the work towards that probably wider change in this RFC. There are two possible scenarios here:

Aliased enum variants require arguments on type, not variant, but normal enum variants still require arguments on variant, not type. This drives towards the new desired syntax for aliased enums only, but introduces inconsistency between aliased and non-aliased enums, which somewhat defeats the purpose of this RFC to make aliases more similar to the original enums.
Both aliased and non-aliased enum variants start preferring arguments on types, not variants; for aliased enums, they are required (since they're new anyway); for non-aliased enums variant arguments are deprecated (and presumably removed in the next epoch).

In the end, I think the change to move arguments from the variant to the type warrants its own discussion, since it a lot of code already out there, whereas this RFC restricts itself to slightly extending the allowed syntax to make aliases more useful. To maintain consistency (which I think are important to the ergonomics of aliases in general) the same rules should IMO apply to aliased and non-aliased enums.

petrochenkov · 2018-02-23T09:24:43Z

cc #2218 ("Generics: Make enum variant syntax consistent with other types")

nox · 2018-02-25T14:48:59Z

This would help Stylo a lot, which has a ton of type aliases to enums, and we need to import both the type alias and the enum it is based on if we want to build values of that type.

aturon · 2018-02-28T20:18:51Z

Nominated for discussion in a lang team meeting.

withoutboats · 2018-03-05T04:05:17Z

Removing I-nominated. I recall that we were generally in support of this feature, I think @nikomatsakis or @cramertj had more comments.

djc · 2018-03-05T08:56:09Z

The meeting agenda/notes mentioned this:

Type alias enum variants
- Allows to refer to enum variants through a type alias
- Move to FCP to accept

aturon · 2018-03-09T19:31:12Z

We discussed this RFC in the lang team meeting, and would like to move it into formal review. It has addressed the open questions that prevented us from previously accepting a PR on this topic.

@rfcbot fcp merge

rfcbot · 2018-03-09T19:31:13Z

Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

petrochenkov · 2018-03-09T19:35:11Z

@rfcbot concern #2338 (comment)

djc · 2018-03-26T08:02:01Z

@nikomatsakis since a majority of the reviewers has approved now, can this enter FCP?

rfcbot · 2018-03-26T08:30:15Z

🔔 This is now entering its final comment period, as per the review above. 🔔

warlord500 · 2018-03-29T15:14:45Z

if this rfc, were to be added to the compiler the following piece of code should compile correct?

enum Bar<T> {
  Test(i32),
  Data(T),
}

type Foo<T> = Bar<T>;
fn main() {
 let _may = Foo::Test::<i32>(1);
}

I do think it is weird were we put the type annotation. i feel like it should be closer to the type like

Vec::<i32>::new()

It seems inconsistent to me. I am safe in assuming that there will be no more additional enum type annotation syntax?

djc · 2018-03-31T13:15:48Z

@warlord500 as explained quite clearly in the reference-level explanation, Foo::Test::<i32> is indeed the syntax made legal by this RFC. Note that, analogously, Bar::Test::<i32> is already how this is spelled today, so the changes from this RFC are orthogonal to the issue of how type arguments are passed to enum variants.

warlord500 · 2018-04-01T05:58:56Z

I am gonna apologize here! some of this comment, may come off as arrogant! also for possible any additional confusion this might add. Writing is not my strongest skill.
I have no intention of belittling anybody, let alone @djc. my assumptions on the last question was yes or no answers. which clearly was not received as intended.

I am gonna start off with, just because you find something clear doesn't
mean somebody else, finds the it clear.

In fact the very reason, I asked my question was to make sure I completely understood the RFC.
I believe me and you @djc have different definitions of syntax!
for example I define for something to be syntactically correct. it has to follow the correct grammar of the language. so for English it is subject verb object!
for example the sentence "the swing is below the water and above the water!" is grammatically correct.
but doesn't make any sense. unless we expand or change the meaning of the words above or below.
"run,skip,jump" are simply sentence fragments not useful, nor helpful on their own!

As, I understand the RFC as now, this doesn't change grammar but does expand the possible interpretations of foo::Test::(1); access foo which can be module or enum or struct,
access Test function or variant, fill generic argument 1 with i32, and call it with the value 1.
expands the access foo part so that to foo can be a type alias to enum, if the access is type alias so replace with it with the aliased type.

if my understanding of rust the language is wrong please correct me. It is never a bad time to learn.
In addition, as I understood your comment, the answer to my first question is yes,.
while the answer to my second answer is no!
if the second answer is yes, then the RFC needs to be changed to be more clear on how it changes the syntax!

If the first question's answer is no, then this RFC needs to be made clear in its entirety.
If the opposite, then I fully support the RFC. while I was testing this, I actually thought my last question would compile as is current rust. my only hope is that the RFC could be made clearer.
their are usage of words, I believe are used different than widely used definitions!

thank you, for reading my extremely long rant!

djc · 2018-04-01T11:37:01Z

This RFC is indeed not intended to change the syntax. It just extends the semantics of the language so that referring to variants into aliased enums is now legal. I hope that clarifies things for you.

warlord500 · 2018-04-01T21:27:17Z

thank you for short and sweet answer to my questions. @djc

rfcbot · 2018-04-05T08:35:42Z

The final comment period is now complete.

Centril · 2018-04-05T08:45:53Z

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#49683

alexreg · 2018-11-26T04:06:18Z

text/2338-type-alias-enum-variants.md

+type Alias<T> = Option<T>;
+
+mod foo {
+    pub use Alias::Some;


I'm inclined to think this shouldn't be allowed, or at least it shouldn't be part of the initial implementation. After all, even

pub use Option::Some;

does not work right now, although

pub use ::std::option::Option::Some;

does, however.
For me, the semantics are unclear, and I'd be inclined not to accept it by default.

Anyway, would appreciate the thoughts of @rust-lang/lang on this matter.

Yes, this can't work right now.
Option::Some is module-relative (enums and traits are kind of modules from name resolution's point of view), so they can be used in imports.
Alias::Some is type-relative, and we need type checking to determine what Alias actually refers to, so it cannot be used in imports due to phase separation.

@petrochenkov

Implement RFC 2338, "Type alias enum variants" This PR implements [RFC 2338](rust-lang/rfcs#2338), allowing one to write code like the following. ```rust #![feature(type_alias_enum_variants)] enum Foo { Bar(i32), Baz { i: i32 }, } type Alias = Foo; fn main() { let t = Alias::Bar(0); let t = Alias::Baz { i: 0 }; match t { Alias::Bar(_i) => {} Alias::Baz { i: _i } => {} } } ``` Since `Self` can be considered a type alias in this context, it also enables using `Self::Variant` as both a constructor and pattern. Fixes issues #56199 and #56611. N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the [tracking issue](#49683)), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible. ```rust Option::<u8>::None; // OK Option::None::<u8>; // OK, but lint in near future (hard error next edition?) Alias::<u8>::None; // OK Alias::None::<u8>; // Error ``` I do not know if this will need an FCP, but let's start one if so. r? @petrochenkov

@petrochenkov

Implement RFC 2338, "Type alias enum variants" This PR implements [RFC 2338](rust-lang/rfcs#2338), allowing one to write code like the following. ```rust #![feature(type_alias_enum_variants)] enum Foo { Bar(i32), Baz { i: i32 }, } type Alias = Foo; fn main() { let t = Alias::Bar(0); let t = Alias::Baz { i: 0 }; match t { Alias::Bar(_i) => {} Alias::Baz { i: _i } => {} } } ``` Since `Self` can be considered a type alias in this context, it also enables using `Self::Variant` as both a constructor and pattern. Fixes issues #56199 and #56611. N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the [tracking issue](#49683)), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible. ```rust Option::<u8>::None; // OK Option::None::<u8>; // OK, but lint in near future (hard error next edition?) Alias::<u8>::None; // OK Alias::None::<u8>; // Error ``` I do not know if this will need an FCP, but let's start one if so.

Type alias enum variants

1a05e39

scottmcm added the T-lang Relevant to the language team, which will review and decide on the RFC. label Feb 15, 2018

aturon self-assigned this Feb 28, 2018

aturon added the I-nominated label Feb 28, 2018

withoutboats removed the I-nominated label Mar 5, 2018

petrochenkov mentioned this pull request Mar 5, 2018

Enum variants completely shadow inherent associated functions. rust-lang/rust#48758

Open

rfcbot added the proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. label Mar 9, 2018

rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Mar 26, 2018

anirudhb mentioned this pull request Apr 4, 2018

type items do not work with enums rust-lang/rust#26264

Closed

Centril mentioned this pull request Apr 5, 2018

Tracking issue for RFC 2338, "Type alias enum variants" rust-lang/rust#49683

Closed

4 tasks

RFC 2338

7499ac5

Centril merged commit 1c851e0 into rust-lang:master Apr 5, 2018

killercup mentioned this pull request May 2, 2018

May 2018 Rustaceans/rust-cologne#51

Closed

11 tasks

ExpHP mentioned this pull request Jul 6, 2018

Using variant on self type with path Self::Variant causes subpar diagnostic rust-lang/rust#52118

Closed

Centril added A-paths Path related proposals & ideas A-typesystem Type system related proposals & ideas A-resolve Proposals relating to name resolution. labels Nov 23, 2018

alexreg reviewed Nov 26, 2018

View reviewed changes

petrochenkov mentioned this pull request Jan 15, 2019

Tracking issue for future-incompatbility lint ambiguous_associated_items rust-lang/rust#57644

Open

3 tasks

Centril mentioned this pull request Jun 9, 2019

Stabilize type_alias_enum_variants in Rust 1.37.0 rust-lang/rust#61682

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Type alias enum variants #2338

Type alias enum variants #2338

djc commented Feb 15, 2018 •

edited by Centril

Loading

WiSaGaN commented Feb 19, 2018

djc commented Feb 19, 2018

petrochenkov commented Feb 21, 2018

petrochenkov commented Feb 21, 2018 •

edited

Loading

djc commented Feb 22, 2018

petrochenkov commented Feb 23, 2018 •

edited

Loading

nox commented Feb 25, 2018

aturon commented Feb 28, 2018

withoutboats commented Mar 5, 2018

djc commented Mar 5, 2018

aturon commented Mar 9, 2018

rfcbot commented Mar 9, 2018 •

edited by pnkfelix

Loading

petrochenkov commented Mar 9, 2018

djc commented Mar 26, 2018

rfcbot commented Mar 26, 2018

warlord500 commented Mar 29, 2018 •

edited

Loading

djc commented Mar 31, 2018

warlord500 commented Apr 1, 2018 •

edited

Loading

djc commented Apr 1, 2018

warlord500 commented Apr 1, 2018

rfcbot commented Apr 5, 2018

Centril commented Apr 5, 2018

alexreg Nov 26, 2018

petrochenkov Nov 26, 2018

Type alias enum variants #2338

Type alias enum variants #2338

Conversation

djc commented Feb 15, 2018 • edited by Centril Loading

WiSaGaN commented Feb 19, 2018

djc commented Feb 19, 2018

petrochenkov commented Feb 21, 2018

petrochenkov commented Feb 21, 2018 • edited Loading

djc commented Feb 22, 2018

petrochenkov commented Feb 23, 2018 • edited Loading

nox commented Feb 25, 2018

aturon commented Feb 28, 2018

withoutboats commented Mar 5, 2018

djc commented Mar 5, 2018

aturon commented Mar 9, 2018

rfcbot commented Mar 9, 2018 • edited by pnkfelix Loading

petrochenkov commented Mar 9, 2018

djc commented Mar 26, 2018

rfcbot commented Mar 26, 2018

warlord500 commented Mar 29, 2018 • edited Loading

djc commented Mar 31, 2018

warlord500 commented Apr 1, 2018 • edited Loading

djc commented Apr 1, 2018

warlord500 commented Apr 1, 2018

rfcbot commented Apr 5, 2018

Centril commented Apr 5, 2018

alexreg Nov 26, 2018

Choose a reason for hiding this comment

petrochenkov Nov 26, 2018

Choose a reason for hiding this comment

djc commented Feb 15, 2018 •

edited by Centril

Loading

petrochenkov commented Feb 21, 2018 •

edited

Loading

petrochenkov commented Feb 23, 2018 •

edited

Loading

rfcbot commented Mar 9, 2018 •

edited by pnkfelix

Loading

warlord500 commented Mar 29, 2018 •

edited

Loading

warlord500 commented Apr 1, 2018 •

edited

Loading