Types for enum variants #1450

nrc · 2016-01-07T20:39:49Z

Edit: this RFC is now only about variant types, the unions stuff is removed in favour of #1444

This is something of a two-part RFC, it proposes

making enum variants first-class types,
untagged enums (aka unions).

The latter is part of the motivation for the former and relies on the former to
be ergonomic.

In the service of making variant types work, there is some digression into
default type parameters for functions. However, that needs its own RFC to be
spec'ed properly.

This is something of a two-part RFC, it proposes * making enum variants first-class types, * untagged enums (aka unions). The latter is part of the motivation for the former and relies on the former to be ergonomic. In the service of making variant types work, there is some digression into default type parameters for functions. However, that needs its own RFC to be spec'ed properly.

sgrif · 2016-01-07T20:51:37Z

text/0000-variant-types.md

+
+Importing an enum imports it into both the value and type namespace. Importing
+a variant imports it only into the value namespace. To maintain backwards
+compatibility, this will remain the default. In order to import an enum variant


Is this actually required for backwards compatibility? I don't think there's currently a way you can have a variant in scope and have a type with the same name.

Huh, looks like you're right, that is good news!

I can't check the code right now, but it looks like variants are already imported into both namespaces (and I do remember that they are defined in both namespaces):

use E::V; enum E { V { field: u8 } } type V = u8; // Conflicts as expected fn main() { let e = V{field: 0}; // Compiles as expected match e { V{..} => {} // Compiles as expected } }

I can't check the code right now, but it looks like variants are already imported into both namespaces (and I do remember that they are defined in both namespaces):

I was wondering about that, I know we tried to prepare for the possibility that variants would become types...

mahkoh · 2016-01-07T21:01:04Z

#[repr(union)]
enum X {
    A {
        alpha: u8,
    },
    B(u8),
}

struct Y {
    x: X,
}

Given y: Y, how do I access alpha?

nrc · 2016-01-07T21:06:32Z

@mahkoh

fn foo(y: Y) {
    let a = unsafe { y.x as X::A };
    println!("alpha: {}", a.alpha);
}

mahkoh · 2016-01-07T21:08:42Z

@nrc This means that modifying any field in a union in a struct requires

Copying the union field out of the struct,
Making the modification,
Copying the field back into the struct.

In the presence of nested unions, repeat. This seems to be extremely inefficient and unergonomic since unions are very often used as struct fields.

mahkoh · 2016-01-07T21:09:42Z

Furthermore, what happens if the union doesn't implement Copy?

nrc · 2016-01-07T21:14:35Z

Should work by reference too:

fn foo(mut y: Y) {
    let a = unsafe { &mut y.x as &mut X::A };
    *a = 42;
}

I should add casts of the reference types to the RFC too.

mahkoh · 2016-01-07T21:15:32Z

Also I believe that one of your arguments against the other RFC was that it requires unsafe code even if you already know the variant. This can be easily solved by taking the idea from this RFC and applying it to the other RFC:

union X {
    f1: T1,
    f2: T2,
}

let x: X = ...
let y: &T1 = unsafe { &x as &T1 };

retep998 · 2016-01-07T21:21:30Z

Let's look at a simple example of a union I already deal with in winapi.

https://github.com/retep998/winapi-rs/blob/master/src/wincon.rs#L17-L25

The original in C looks like:

typedef struct _KEY_EVENT_RECORD {
    BOOL bKeyDown;
    WORD wRepeatCount;
    WORD wVirtualKeyCode;
    WORD wVirtualScanCode;
    union {
        WCHAR UnicodeChar;
        CHAR   AsciiChar;
    } uChar;
    DWORD dwControlKeyState;
} KEY_EVENT_RECORD;

Under this RFC in Rust it would look like:

STRUCT!{struct KEY_EVENT_RECORD {
    bKeyDown: ::BOOL,
    wRepeatCount: ::WORD,
    wVirtualKeyCode: ::WORD,
    wVirtualScanCode: ::WORD,
    uChar: KEY_EVENT_RECORD_uChar,
    dwControlKeyState: ::DWORD,
}}
#[repr(union)] enum KEY_EVENT_RECORD_uChar {
    UnicodeChar(::WCHAR),
    AsciiChar(::CHAR),
}

Since I cannot conveniently import UnicodeChar into the global namespace (union variants are not in the global namespace in C so there may be other identifiers with the same name) that means users would have to fully specify that type, which is kinda ugly:

let x: KEY_EVENT_RECORD = ...;
let y = x.uChar as KEY_EVENT_RECORD_uChar::UnicodeChar;

Meanwhile in C someone could just do x.uChar.UnicodeChar. They can even mutate the variant in place instead of having to do x.uchar = KEY_EVENT_RECORD_uChar::UnicodeChar(foo).

With my current macro solution the user can call inherent methods to get (mutable) references to the variant, which is almost as good as direct field access. Any RFC for unions needs to provide syntax that is better than what I currently have, which means direct field access is really important.

nrc · 2016-01-07T21:58:06Z

@retep998 I don't think that direct field access is a very Rust-y solution - it's an unsafe operation which doesn't indicate why/in what way it is unsafe. I think the casting should extend to (mutable) references, and within a scope you can bring in enum variants as types, so you have a clear two line solution instead of an unclear one solution, which seems not too bad:

fn foo(x: KEY_EVENT_RECORD) {
    use KEY_EVENT_RECORD_uChar::*;

    let y = unsafe { &mut x.uChar as &mut UnicodeChar };
    y.0 = 42; 
}

You could stick that all on one line if you like, but I admit that gets pretty ugly.

eddyb · 2016-01-07T23:16:17Z

text/0000-variant-types.md

+expression - both the variant type and the enum type. If there is no further
+information to infer one or the other type, then the type checker uses the enum
+type by default. This is analogous to the system we use for integer fallback or
+default type parameters.


This is great, pretty much what I expected and @nikomatsakis also confirmed it's what he would do (although him and @aturon aren't sure it's enough i.e. compared to full subtyping).

Note that it gets a bit more complicated if we also support nested enums, though probably the fallback would just be to the root in that case.

Yes, I wanted to add that with nested enums we would have a chain of potential types to infer to, but I realized that nested enums aren't in the scope of this RFC.

mahkoh · 2016-01-07T23:37:07Z

I don't think that direct field access is a very Rust-y solution - it's an unsafe operation which doesn't indicate why/in what way it is unsafe

The same applies to calling an unsafe method.

You could stick that all on one line if you like

You have to do either that or introduce another scope due to lexical lifetimes. More realistically, the code would look like this:

fn f(mut x: Struct1) {
    {
        use KEY_EVENT_RECORD_uChar::*;

        let y = unsafe { &mut x.f as &mut Variant1 };
        y.0 = 42; 
    }
    g(&x);
}

And when you have nested enums then it gets really funny.

eddyb · 2016-01-07T23:42:38Z

text/0000-variant-types.md

+inheritance: if we allow nested enums, then there are many more possible types
+for a variant, and generally more complexity. If we allow data bounds (c.f.,
+trait bounds, e.g., a struct is a bound on any structs which inherit from it),
+then perhaps enum types should be considered bounds on their variant types.


Perhaps we can retain only trait bounds and use e.g. V: VariantOf<E> - which is what I've used in my version of the examples in @nikomatsakis' blog post introducing many of these ideas.

mahkoh · 2016-01-07T23:48:24Z

Tbqh, if this is the union accepted union implementation, then I'll just continue to do what I do right now: Add two methods per variant (variant, variant_mut) and transmute the passed reference. Code like that already works and it will be shorter than this. The only thing gained by this implementation is that one can have a type with the correct size and alignment. But once ctfe becomes better, that will be possible without this implementation too.

strega-nil · 2016-01-07T23:50:58Z

I love this proposal, thank you for coming up with it. It still needs a little work, but it is the best thing I've seen so far and works well in the fledgeling memory model that will be released soon.

LaylBongers · 2016-01-08T00:33:40Z

Here is an alternative proposal for syntax on unions, anything but final but as a rough idea:

struct KEY_EVENT_RECORD {
    bKeyDown: ::BOOL,
    wRepeatCount: ::WORD,
    wVirtualKeyCode: ::WORD,
    wVirtualScanCode: ::WORD,
    uChar: KEY_EVENT_RECORD_uChar,
    dwControlKeyState: ::DWORD,
}

c_union KEY_EVENT_RECORD_uChar {
    unicode_char: ::WCHAR,
    ascii_char: ::CHAR,
}

// Accessing:
let mut record = foo();
{
    // Immutable Ref
    let unicode_c = unsafe { record.wChar.as_unicode_char() };
}
{
    // Mutable Ref
    let ascii_c = unsafe { record.wChar.as_ascii_char_mut() };
}

Setting is still undetermined. My main issue with this syntax would be that adding methods feels too magic-y for rust, but I feel they're important to communicate what's unsafe about what's being done. I want to try to fit in a #[derive(_)] in there to mitigate that, but c_union wouldn't have any use without the derive so it feels wrong to add it.

strega-nil · 2016-01-08T01:12:49Z

I could see this going a few ways:

// This is a simplified struct from WinAPI
#[repr(union)]
enum tagVARIANTvariant {
    llVal(LONGLONG),
    lVal(LONG),
    bVal(BYTE),
    iVal(SHORT),
}

#[repr(union)]
enum tagVARIANTtag {
    __tagVARIANT {
        vt: VARTYPE,
        variant: tagVARIANTvariant,
    },
    // other fields here I've taken out
}

struct tagVARIANT {
    tag: tagVARIANTtag,
}

fn test() {
    let x: tagVARIANT;
    // This is the safest bet. However, it's also a pain to use, and it's unlikely that FFI people
    // will go along with it
    (x.tag as tagVARIANTtag::__tagVARIANT).vt = LLVAL;
    (x.tag as tagVARIANTtag::__tagVARIANT).variant = tagVARIANTvariant::llval(100);

    // We could also automatically import the types. This is backwards compatible in the `as` field,
    // although I'm less certain about the = field. This would also make normal enums nicer to use,
    // and I've heard talk of doing this with match statements.
    (x.tag as __tagVARIANT).vt = LLVAL;
    (x.tag as __tagVARIANT).variant = llval(100);

    // This is the last suggestion, and my least favorite. However, if we can't find a solution, we
    // may have to go with it :/
    x.tag.__tagVARIANT.vt = LLVAL;
    x.tag.__tagVARIANT.variant = tagVARIANTvariant::llval(100);
}

To clarify what I'm talking about with match statements, some have talked about:

enum E {
    Var0,
    Var1,
}

match E { // this would be okay, despite never `use`ing Var0 or Var1
    Var0 => {},
    Var1 => {},
}

mahkoh · 2016-01-08T01:22:01Z

There is also a need for non-anonymous variants. E.g.

#[repr(C)]
struct TagVariant {
    vt: VARTYPE,
    variant: tagVARIANTvariant,
}

#[repr(union)]
enum tagVARIANTtag {
    __tagVARIANT: TagVariant,
    // other fields here I've taken out
}

strega-nil · 2016-01-08T01:43:31Z

@mahkoh That's covered by tagVARIANTvariant.

mahkoh · 2016-01-08T01:47:37Z

@ubsan So every access additionally requires a .0?

strega-nil · 2016-01-08T01:50:49Z

@mahkoh If you're doing it that way, yes, I assume.

mahkoh · 2016-01-08T13:48:23Z

This RFC deals with two orthogonal issues:

Allowing enum variants to be used as types
Allowing the discriminant to be removed from enums

Therefore it should be split into two RFCs.

eddyb · 2016-01-08T14:36:08Z

I agree with @mahkoh, as I believe that enum variants as types is less controversial of a feature, and it's an important step towards empowering ADT hierarchies.

japaric · 2016-01-08T15:14:51Z

text/0000-variant-types.md

+
+## impls
+
+`impl`s may exist for both enum and variant types. There is no explicit sharing


Would this let us fix rust-lang/rust#5244? Example:

enum Option<T> { Some(T), None, } // we add this impl<T> Copy for Option<T>::None {} // then, either this just works let x: [Option<String>; 10] = [None; 10]; // or this works (can this be written without the temporary `t`?) let t: [Option<String>::None; 10] = [None; 10]; let x: [Option<String>; 10] = t;

It would likely require that the variant types have the same size as the enum itself, so they'd have to have unused padding for things like the discriminant.

That is the case according to the RFC.

The correct solution here is not using Copy directly, i.e. by either allowing constants, or ADTs of Copy-able types.

While @japaric's proposal may be equivalent to the latter option, let x: [Option<String>; 10] = [None; 10]; would not work with this RFC as written because None would infer to Option<String> which is not Copy - and there is no conversion from [None<T>; N] to [Option<T>; N] (but there could be? not sure what we can do here).

On Fri, Jan 08, 2016 at 07:14:59AM -0800, Jorge Aparicio wrote:

Would this let us fix rust-lang/rust#5244?

Yes, perhaps, that's one of the appealing things about having variants
be types.

On Fri, Jan 08, 2016 at 10:06:19AM -0800, Eduard-Mihai Burtescu wrote:

While @japaric's proposal may be equivalent to the latter option, let x: [Option<String>; 10] = [None; 10]; would not work with this RFC as written because None would infer to Option<String> which is not Copy - and there is no conversion from [None<T>; N] to [Option<T>; N] (but there could be? not sure what we can do here).

In the RFC as written, I think something like [None: None<String>; 32] would be required?

nikomatsakis · 2016-01-08T22:31:45Z

There is a lot here. I'll just try to write some comments as I digest (and catch up on the already lengthy comment thread).

First, I'm not a big fan of foo as Variant downcasting. It's good for unions but kind of "bad style" elsewhere and I'm not sure we need to add it; I'd prefer to encourage people to write if let or match, just as they do today.

Second, I would love to have variants be types, but the integration described in the RFC sounded a bit rougher than I would like. I guess I have to process it more, as the RFC has a number of particular mechanisms, and it's hard for me to judge if they are good choices or not. This may also be something we can also expect to hammer on and experiment with in the implementation phase, but it'd be good to think hard about the rough edges that we expect to emerge.

Finally, on the topic if unions in particular. It's certainly the case that a #[repr(union)] annotation feels more natural on an enum than on a struct, but I also find something in #1444 very appealing. Certainly it's a much more targeted addition, which I like. I also like that you use field projection foo.bar to select which variant you want -- it feels like an "active selection", whereas matching does not. (as, admittedly, feels good too -- but then as seems to be sugar for match, and match feels wrong, since I expect that in a match the compiler will pick which arm, not me.)

petrochenkov · 2018-02-23T09:34:52Z

The "postponed" issue for this RFC was never created, so I've made one - #2347.

alexreg · 2018-05-15T01:54:09Z

Any chance of this being revisited soon?

nielsle · 2018-05-15T04:01:36Z

For the sake of posterity. The following pattern combined with crates such as https://github.com/JelteF/derive_more and https://github.com/DanielKeep/rust-custom-derive allows you to do some of the stuff mentioned in the RFC.

struct Variant1( i32, String );
struct Variant2 { f1: i32, f2: String };

pub enum Foo {
    Variant1(Variant1),
    Variant2(Variant2),
}

So if the RFC is revived, then the pattern should probably be discussed under alternatives.

The instructions of QASM are classified in a hierarchy, I've tried to implement them in the form of several enums but extending enums is not supported in Rust (yet). https://stackoverflow.com/questions/25214064/can-i-extend-an-enum-with-additional-values The hierarchy is mostly related to QuantumOperation and UnitaryOperation. A UnitaryOperation is always a QuantumOperation but not the other way around. I went for the wrapping alternative which will make getting the value a bit tedious. I hope to be able of implementing some traits to ease this task but without rust-lang/rfcs#1450 it could be difficult. In reality, this hierarchy is not strictly neccessary, I could have grouped all the instructions in the same enum and let the grammar accept those programas that use the different operations correctly, but I wanted to experiment with a proper separation of instruction types. Let's see. Perhaps, a different approach would be following this Thin Traits proposal: http://smallcultfollowing.com/babysteps/blog/2015/10/08/virtual-structs-part-4-extended-enums-and-thin-traits/

alexreg · 2018-08-22T02:30:32Z

@nrc Any chance of getting this RFC reopened now, and potentially merged soon? I have a couple of things I'm working on now, but I'd be willing to take this on afterwards perhaps.

eddyb · 2018-08-22T02:40:40Z

@alexreg You'd probably need to ask @nikomatsakis about the status of what'd be needed to implement this.

alexreg · 2018-08-22T03:29:22Z

Okay, hopefully @nikomatsakis will see this comment and reply here.

Ericson2314 · 2018-08-22T07:52:42Z

"Safe unions", non-lexical &move liveness, and non-lexical enum variant type are all related. I'd love to have all 3!

leonardo-m · 2018-08-22T08:34:15Z

I have a question regarding enum variants as types, is this going to be correct?

fn main() {
    use std::mem::size_of;
    assert_eq!(size_of::<Option<u32>>(), 8);
    assert_eq!(size_of::<Some<u32>>(), 4);
}

eddyb · 2018-08-22T09:49:42Z

@leonardo-m I don't think so, since we'd want to allow coercing &Some<u32> to &Option<u32>, which means it must already be the full size of the enum and have the tag set to 1.

alexreg · 2018-08-22T17:14:05Z

@Ericson2314 Is there a proposal for "safe unions"? I don't know what that means. Unless perhaps it's similar to one of the ideas suggested here. No idea what the other two mean either. :-P

jeffreydecker · 2018-09-24T19:39:55Z

I would love to see this get in at some point in the future. Allowing for variants to impl traits on their own would be a nice alternative to requiring a match to essentially do the same.

I'm beginning to use enum variants to help represent states in a state machine and this would go a long way in making the experience a bit better, mainly with regard to code organization.

The pattern referenced above by @nielsle is valid and I have tried it out. IMO it's not nearly as readable/understandable or even maintainable as supporting variants as first class types would be. I've actually stuck with using pure enum variants as opposed to that pattern because of this.

alexreg · 2018-09-24T20:08:20Z

@jeffreydecker I think a bunch of us would like the feature! Fancy writing an RFC? ;-) You could easily get some help from folks here or on Discord, I reckon.

nrc · 2018-09-24T21:14:56Z

The blocking thing for this feature is properly understanding default type parameters and the interaction with the various kinds of fallbacks to defaults (e.g., numeric fallbacks). I think once we understand that a bit better, then we could re-open this RFC (or something like it).

alexreg · 2018-09-24T21:26:58Z

Ah, fair enough. We already have default type parameters though, so I don't see the problem.

burdges · 2018-09-25T01:01:47Z

There is another concern in that refinement types would ideally extend enum variant types and be useful for formal verification, so an RFC would ideally consider those possible future directions.

alexreg · 2018-09-25T01:44:29Z

I think that would be coming a very long way off, if ever... probably not worth much thought at this point.

varkor · 2018-11-10T17:30:16Z

I've submitted an RFC to follow up on this one and permit enum variants to be treated as types:
Enum variant types.

nrc added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jan 7, 2016

nrc self-assigned this Jan 7, 2016

nrc mentioned this pull request Jan 7, 2016

unions #1444

Merged

sgrif reviewed Jan 7, 2016
View reviewed changes

eddyb reviewed Jan 7, 2016
View reviewed changes

japaric reviewed Jan 8, 2016
View reviewed changes

petrochenkov mentioned this pull request Feb 23, 2018

Types for enum variants #2347

Closed

petrochenkov mentioned this pull request Feb 23, 2018

Enum Type #2346

Closed

lu-zero mentioned this pull request Feb 23, 2018

Would be nice to have trait impl bound to enum variants rust-av/rust-av#48

Open

Centril added the postponed RFCs that have been postponed and may be revisited at a later time. label Feb 26, 2018

jeremyBanks mentioned this pull request Jul 15, 2018

Use codes::Instruction in emulator::CPU jeremyBanks/0dmg#11

Closed

nrc mentioned this pull request Nov 10, 2018

Enum variant types #2593

Closed

SimonSapin mentioned this pull request Dec 26, 2018

RFC: Using enums like traits #2618

Closed

parker-codes mentioned this pull request Jan 27, 2021

Simplify Command Matching tauri-apps/tauri#1157

Closed

harudagondi mentioned this pull request Nov 12, 2022

Entity Markers bevyengine/bevy#6556

Open

smklein mentioned this pull request Jun 28, 2023

Unify services and datasets, external and internal DNS are datasets too oxidecomputer/omicron#3390

Merged

GwnDaan mentioned this pull request Aug 10, 2023

Add core address claiming logic Open-Agriculture/AgIsoStack-rs#15

Merged

TheLimePixel mentioned this pull request Mar 30, 2024

Allow sum types' subtypes to be used as their own types TheLimePixel/bento#3

Open


		## impls

		`impl`s may exist for both enum and variant types. There is no explicit sharing

Types for enum variants #1450

Types for enum variants #1450

Conversation

nrc commented Jan 7, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mahkoh commented Jan 7, 2016

nrc commented Jan 7, 2016

mahkoh commented Jan 7, 2016

mahkoh commented Jan 7, 2016

nrc commented Jan 7, 2016

mahkoh commented Jan 7, 2016

retep998 commented Jan 7, 2016

nrc commented Jan 7, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mahkoh commented Jan 7, 2016

Choose a reason for hiding this comment

mahkoh commented Jan 7, 2016

strega-nil commented Jan 7, 2016

LaylBongers commented Jan 8, 2016

strega-nil commented Jan 8, 2016

mahkoh commented Jan 8, 2016

strega-nil commented Jan 8, 2016

mahkoh commented Jan 8, 2016

strega-nil commented Jan 8, 2016

mahkoh commented Jan 8, 2016

eddyb commented Jan 8, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Jan 8, 2016

petrochenkov commented Feb 23, 2018

alexreg commented May 15, 2018

nielsle commented May 15, 2018

alexreg commented Aug 22, 2018

eddyb commented Aug 22, 2018

alexreg commented Aug 22, 2018

Ericson2314 commented Aug 22, 2018

leonardo-m commented Aug 22, 2018 • edited Loading

eddyb commented Aug 22, 2018

alexreg commented Aug 22, 2018

jeffreydecker commented Sep 24, 2018

alexreg commented Sep 24, 2018

nrc commented Sep 24, 2018

alexreg commented Sep 24, 2018 • edited Loading

burdges commented Sep 25, 2018

alexreg commented Sep 25, 2018

varkor commented Nov 10, 2018 • edited Loading

leonardo-m commented Aug 22, 2018 •

edited

Loading

alexreg commented Sep 24, 2018 •

edited

Loading

varkor commented Nov 10, 2018 •

edited

Loading