Enum with associated values

[bernardnormier]

This is a proposal to add associated values to Slice enum, similar to Swift and Rust.
See:
https://docs.swift.org/swift-book/LanguageGuide/Enumerations.html
https://doc.rust-lang.org/rust-by-example/custom_types/enum.html

The syntax of Slice enums with associated values is similar to Rust/Swift:

enum WebEvent
{
    PageLoad,
    PageUnload,
    KeyPress(byte key),
    Paste(string str),
    Click(long x, long y)
}

Syntactically, it's similar to an operation with parameters and no return value.

A Slice enum where any enumerator has one or more associated values:

• cannot be unchecked
• cannot have an explicit value for any of its enumerators (like = 5)
• cannot have an underlying integer type (like enum WebEvent : byte)

In C#, WebEvent and its enumerators would map to a small generated record hierarchy:

public record WebEvent
{
    public sealed record PageLoad() : WebEvent;
    public sealed record PageUnload() : WebEvent;
    public sealed record KeyPress(byte Key) : WebEvent;
    public sealed record Paste(string Str) : WebEvent;
    public sealed record Click(long X, long Y) : WebEvent;
}

Usage: https://dotnetfiddle.net/LH5C6q

This also works well with switch case and switch expression, since we can match on the type (like WebEvent.KeyPress).

[pepone]

How will we encode these enumerators, I assume we encode each using a struct with a type ID, and enumerators without associated values, encode like an empty struct of the given type.

[InsertCreativityHere]

I had thought it'd be something like:

enum MyEnum: byte
{
    Foo,
    Bar(String),
}

for Foo we'd encode [0]
for Bar we'd encode [1][String]
In general we'd enum [value as enum backing type][data stored in enumerator, in order]

We really don't even need type-IDs here, since we know exactly what type will be passed in.

[InsertCreativityHere]

One question I see is whether we should allow tags here...

enum MyEnum
{
    Foo(tag(1) String?),
}

I think allowing optionals is totally fine, but tags, I don't know. I think it's fine to not support them, making enumerators effectively like compact structs.

[pepone]

I think allowing optional here is more flexible, one option would be to allow using compact as a modifier for enums like we already do for structs.

compat enum ... {} // Enumerator encode as index + compact struct  
enum ... {} // Enumerator encode as index + struct

[bernardnormier]

I lean towards having only compact enums (and hence no compact qualifier) because "regular" enums without associated values should (obviously) be compact.

If we allowed tags in associated values, then enum Letter { A, B, C } is non-compact by default because you can always add a tagged associated value to each of A, B or C:

enum Letter { A, B(foo: tag(1) string?), C }

[InsertCreativityHere]

I agree, supporting tags here seems overkill.

Note that there's nothing wrong with enumerators holding non-compact structs, so they can still have flexibility in the underlying data:

struct Foo
{
    data: tag(1) int32,
}

enum Bar
{
    Nothing,
    F(Foo),
}

[pepone]

I feel that tags are important because they allow applications to evolve, is true that you can use a struct with tags but you have to anticipate the need, I think that defaulting to evolvability and letting the user opt-in compact and squeeze this extra bit of performance would be best, and it seems like supporting both would not add much complexity.

[bernardnormier]

The first thing we need in terms of extensibility for enums with associated values is to support unchecked enums with associated values. This way, if you don't like an existing associated value, you can introduce a new discriminant with the desired value.

Then we can piggy-back on this extensibility to add tags to the enum's associated values.

Proposal

1. An enum with an underlying type is always encoded as its underlying type. It can't have an associated value.

2. An enum with no underlying type:

• has always an associated value (which can be empty)
• does not support explicit values for its discriminants

3. A checked enum with no underlying type can be marked compact. It means the associated value is logically a compact struct. For enumerators without an associated value, nothing is encoded beyond the discriminant.

For example:

compact enum Location {
    Unknown
    Anonymous
    Known(coordinates: Coordinates)
} 

Here, Unknown is encoded as 0 (as a varint32), and Known is encoded as 2 (varint32) followed by the coordinates. The Coordinates struct is encoded like a compact struct holding Coordinates.

Without compact, Unknown is encoded as 0 followed by the tag end marker (0xfc), and Known is encoded as 2 (varint32) followed by an anonymous struct that holds the coordinates. This allows associated values to be extended in a wire-compatible manner:

enum Location {
     Unknown(tag(1) name: string?) // wire compatible
     Anonymous
     Known(coordinates: Coordinates)
}

4. an unchecked enum with no underlying type can also be compact or non-compact:

unchecked enum Location {
    Unknown
    Anonymous
} 

compact = tags not allowed + smaller encoding size (1 byte less: not much)
non-compact = tags allowed

Every enumerator is encoded as: [discriminant][boxed value]. The boxed value is a size followed by an anonymous struct (compact or non-compact depending on the enum qualifier).

For example, Unknown is encoded as 0 (discriminant) followed by an 1 (size) followed by the empty struct tag end marker (since the enum is non-compact).

Then, you could extend it with:

unchecked enum Location {
    Unknown
    Anonymous
    Known
} 

and later:

unchecked enum Location {
    Unknown(tag(1) message: string?)
    Anonymous
    Known
    KnownWithCoordinates(coordinates: Coordinates)
} 

During decoding:

• if the Slice engine knows the KnownWithCoordinates enumerator, it will decode it properly
• if the Slice engine does not know the KnownWithCoordinates enumerator, it will decode the discriminant but won't be able to decode the associated value. It can skip this value since it's in a box. It would be nevertheless useful to somehow give the raw sequence<uint8> to the application and support "value preservation". That's a language mapping concern.

[InsertCreativityHere]

Tags are so powerful with structs because they're 'extensible by default'. If you just type struct Foo {...}, you can use tags. Users have to opt-out of this extensibility by adding the compact modifier to it (if they know they don't need the flexiblity and care about performance).

Having enums be 'un extensible by default' makes the feature partially useless in practice. Few users will have the foresight (or even knowledge) to preemptively mark their enums unchecked just in case they need the extensibility in the future.

More likely they'll only write enum Foo {...}, and by the time they realize "wow, I really wish this variant took an extra bool", there's already nothing they can do about it.

---

So, if we go with this approach, I think we'd have to switch the behavior of enums with variants:
They should be "unchecked"/"non-compact" by default, and users can opt into disabling this for performance by applying the checked or compact keyword.

This conclusion is a little unfortunate though, because while "unchecked by default" is ideal for enums with variants, "checked by default" makes more sense for 'normal' enumerators...