Tracking issue for RFC 2338, "Type alias enum variants"

[Centril]

This is a tracking issue for the RFC "Type alias enum variants" (rust-lang/rfcs#2338).

Steps:

• Implement the RFC (Implement RFC 2338, "Type alias enum variants" #56225)
• Adjust documentation (see instructions on forge)
• Stabilization PR (Stabilize type_alias_enum_variants in Rust 1.37.0 #61682)

Unresolved questions:

• Decide how to resolve in case of ambiguities between associate types and variants. (Currently low-priority resolution for variants.) See Implement RFC 2338, "Type alias enum variants" #56225 (comment). Resolved in favour of high-priority resolution with High priority resolutions for associated variants #57501.

[djc]

I'd like to try implementing this. Since there was a previous implementation attempt in #31179, I can probably start off of that, but mentoring instructions would be quite welcome.

[petrochenkov]

Short instructions:

• Find a place where associated types are resolved to their definitions (probably fn associated_path_def_to_ty) and add high-priority resolution to variant definitions.
• Find a place where associated values are resolved to their definitions (probably fn resolve_ufcs) and add high-priority resolution to variant definitions.
• Try to apply the "argument transfer" scheme (Type::AssocItem<Args> -> Type<Args>::AssocItem) to generic arguments of associated items if they resolve to variants. This can meet complications because this is not something that can (or should) be done naturally, as I previously described.

[earthengine]

I have a specific concern on this. Right now, every concrete type name contains information of its component type names, making it very easy to have the name length being explode. Introducing something that making this issue worse may not be a good idea if we haven't get the type names shorted.

Here is an example of how bad this problem can be.

Internally, a type should contain all information to identify itself. But it is not necessary appear in the name, especially when the name is too long, because type names areintended to be read by human, and no one will read a name with a million chars. On the other hand, computer code will feel more comfortable to manipulating referencing structures. So by limiting the type name size we wouldn't lose anything.

To making things worse, I just figured out that the length of a single type is not the issue I experienced. The problem is that there are too many (and too long) type names being generated, and so exceeded the compiler limit. This is why it is getting worse when I extract methods as it forces the compiler to generate more types.

This RFC, once implemented, will add much more types to the system, so please measure a typical closure-heavy-and-impl-trait-heavy program, to see how bad this problem is. It would also be good to allow the compiler to generate statistics of the types it generates, so we can keep tracking this.

[alexreg]

@djc Did you manage to make any headway on the implementation of this?

[djc]

@alexreg no, not yet. Feel free to move forward if you want to take a crack at it!

[alexreg]

Too busy right now, I'm afraid. I'd need more detailed mentoring instructions too, as too many of these concepts are foreign to me... best someone else tackles it.

[pravic]

It was already implemented. Why not to reopen the previous PR?

[alexreg]

@pravic Where’s that PR?

[pravic]

#31179

[alexreg]

Thanks.

[tlively]

Is there anyone currently working on this? I would love to see this RFC implemented. If there were mentoring instructions available I would take a stab at it.

[alexreg]

@tlively Do you feel you need something more detailed than
#49683 (comment)? That's fine if so; maybe ping @petrochenkov or get on Discord. :-)

[djc]

@tlively I'm currently not working on this. Between the stuff that @petrochenkov already wrote here and the earlier implementation attempt I linked from the second comment, I think you should probably have a good starting point to dig in?

[tlively]

Ok, I think I should be able to figure it out. I'll be trying this out over the next few days. Thanks, everyone!

[alexreg]

@tlively Glad to hear! Let us know how you get on.

[tlively]

@alexreg So far it's slow-going, but I'm still chipping away at it!

[alexreg]

@tlively Okay. If you need any help, pop into Discord. Even I may be able to assist you a bit with it.

[leonardo-m]

I was about to open an enhancement request to support code like:

#![feature(self_in_typedefs, box_syntax)]
enum PeanoNumber {
    Zero,
    Succ(Box<Self>),
}
impl PeanoNumber {
    fn add_one(n: Self) -> Self {
        Self::Succ(box n)
    }
}

[alexreg]

Any updates on this lately, @tlively? :-)

[tlively]

No, I wasn’t able to make meaningful progress and I haven’t looked at it in a while. If someone else wants to take a look they should go for it.

[eddyb]

Should this really mention type aliases at all?
I expect <Option<_>>::None to require the exact same implementation, unless it's been hackily implemented today in some other fashion.
Similarly, Self::None should really desugar to <Self>::None and then get resolved by the exact same machinery that type aliases would need.

[petrochenkov]

I still think we should reconsider and not implement the "argument transfer" scheme Type::AssocItem<Args> -> Type<Args>::AssocItem.

[nvzqz]

So for some reason this nightly feature is required when implementing the following macro (found in nvzqz/static-assertions#11):

macro_rules! assert_variant {
    ($e:ty, $v:ident) => {
        const _: fn($e) -> () = |e| match e {
            <$e>::$v => {},
            _ => {},
        };
    }
}

Does anyone have an idea as to why?

[petrochenkov]

@nvzqz
The reason is that the feature is not actually "type alias enum variants", but "type relative enum variants" or "variants as associated items".
When writing <TYPE>::NAME you are asking to search for an associated item named NAME on type TYPE, for variants this kind of requests is feature gated.

The stable solution will look something like:

macro_rules! assert_variant {
    ($e:ident, $v:ident) => {
        const _: fn($e) -> () = |e| match e {
            $e::$v => {},
            _ => {},
        };
    }
}

or

macro_rules! assert_variant {
    ($e:path, $v:ident) => {
        const _: fn($e) -> () = {
            use $e as my_ident; // On 2018 edition, or if `$e` is guaranteed to be a crate-relative path
            |e| match e {
                my_ident::$v => {},
                _ => {},
            }
        };
    }
}

(See also #48067 that would provide a better solution for the second case.)

[nvzqz]

So the issue with using path or ident in this case is that neither supports generic arguments. I would like it such that $e could be any enum, generic or otherwise.

[petrochenkov]

I thinks we can start the stabilization process once the current implementation (#57501) lands on stable.

#57501 is now in the released stable Rust 1.34

[estebank]

Once this is stabilized, we can close #52118 if it hasn't been closed earlier by adding a suggestion to use the enum's path instead of Self.

[Centril]

We discussed this on the language team meeting today and gave the green light for a stabilization report which I (@Centril) will write.

[alexreg]

I should be able to stabilise this if I'm not too busy with other things at the time. (Or @Centril is welcome to after writing the report.)

[Centril]

I will do both things at the same time... :)

[Centril]

I have proposed stabilization in #61682.

[Centril]

Stabilization has been done.

Documentation issue is rust-lang/reference#631.

Everything that needs to be done on rust-lang/rust is done so I'm closing this issue as a result.