Sum types in product types

language design
25

This is an excellent point.

I guess I was only thinking about the case of just pattern matching these objects (because of the use situation I had at the time).

Yes, you absolutely would need to have a type name for any inner type as you can extract

This eliminates any unnamed types within a product type.

However, could you have sum types within sum types? e.g.:

enum X {
    G {A, B, C},
    F {D, E, F},
}

let foo: X = X::G::B;
26

What are you asking is much better to describe with a feature anonymous enums

struct MyStruct {
    x: enum {V1, V2},
    y: f64,
}

let ms : MyStruct = MyStruct { x: enum::V1, y : 2.0 };
let msx  : enum {V1, V2} = ms.x;

As far as I knew all attempts to add this feature into the languages were not accepted. And all attempts to add them by already existed rust-possibilities were abandoned.

2 Likes
29

Yeah, I wouldn't be in support of anonymous enums. Too typescript-esque.

What about the enums within enums thing?

enum X {
    G {A, B, C},
    F {D, E, F},
}

let foo: X = X::G::B;
30

I see no benefits of this. You already could write

enum X {
    G_A,
    G_B,
    G_C,
    F_D, 
    F_E, 
    F_F,
}

let foo: X = X::G_B;

But it's also Ok with anonymous enums:

enum X {
    G (enum {A, B, C}),
    F (enum {D, E, F}),
}

let foo: X = X::G( enum::B);
1 Like
31

but you could match on G instead of G_A, G_B, G_C

32

Within the contexts of programming languages this is called an "unnameable type". It is given a unique type name within the context of compilation, but the code being compiled has no way of referring to it. This might still be allowed:

let ms : MyStruct = MyStruct { x: V1, y : 2.0 };
let msx = &ms.x;

but e.g. you cannot return a &MyStruct.__X__ from a function, because you can't name it. It is not an unmanageable issue as long as the variants have some way of being named (e.g. MyStruct::V1, or MyStruct::_::V1).

Overall this thread might be diverging a little by conflating the idea of declaring enums inline and making those enums anonymous. There is no reason for inline enums to be necessarily anonymous.

struct MyStruct {
    x: enum X {V1, V2},
    y: enum Y {V1, V2},
    z: f64,
}
1 Like
33

Please don’t be overly confrontational. This topic is becoming simultaneously a burden to moderate(1) and the discussion isn’t leading anywhere specifically, as far as I can tell.

For more focused discussion, e.g. on the pros and cons of a proposed language feature, it would make sense to actually propose a language feature, whereas this topic seems to be a broad discussion about the idea to ”declare sum types inside product types” with no syntax to construct values of those types or work with them (e.g. pattern matching).

While one should never by overly harsh in defending language proposals against criticism, it seems particularly strange to me to do so in a context where no fleshed out feature is proposed in the first place.

    (1) this involves replies that are no longer visible

5 Likes