[Enum] generic, constraint, types and named parameters for ADT Enums

[igotfr]

Dart enums are anemics and force us to use class

Dart Proposal

enum Option<T> {
    None,
    Some(T)
}

var functor = Option<int>.Some(4);

enum IpAddr {
    V4(String),
    V6(String)
}

var ip = IpAddr.V4("0.0.0.0");

enum IpAddr {
    V4(int, int, int, int),
    V6(String)
}

var ip = IpAddr.V4(192, 168, 1, 1);

enum Message {
    Quit,
    Move({ int x, int y }),
    Write(String),
    ChangeColor(int, int, int)
}

var message = Message.Move(x: 45, y: -82);

Rust Enums

pub enum Option<T> {
    None,
    Some(T)
}

enum IpAddr {
    V4(String),
    V6(String)
}

enum IpAddr {
    V4(u8, u8, u8, u8),
    V6(String)
}

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32)
}

[mateusfccp]

Duplicate of #349.

[igotfr]

relateds:
#158
#546

[igotfr]

enum Foo {
    Bar,            // 0
    Baz = 123,      // 123
    Quux,           // 124
}

[Levi-Lesches]

I think this can be closed now that the enhanced-enums proposal is being worked on. Issue #158 is the official tracking issue for the topic.

[igotfr]

I think this can be closed now that the enhanced-enums proposal is being worked on. Issue #158 is the official tracking issue for the topic.

I think this is very verbose and unnecessary, I've never seen it anywhere. The variations I know are Haskell's data, Rust's enum, and V's type (sumtype)

https://github.com/vlang/v/blob/master/doc/docs.md#sum-types

[Levi-Lesches]

I don't quite understand your concern. Looking at your examples, you seem to be asking for a way to give enums parameters and fields, like regular classes. I see that some of your examples don't take any arguments, or have a different signature than the other elements of the enum, but that's a smaller detail. The enhanced-enums proposal gives you the ability to treat enums like regular classes. Combine that with the idea of enum-like classes and you should be fine. Your first example would be something like:

/// Enum-like class -- works today.
class Option<T> {
  final int? value;
  const Option([this.value]);

  static const none = Option();
  static const functor = Option<int>(4);
}

/// Enhanced enum -- requires the enhanced-enum feature.
enum Option<T> {
  none(),
  functor<int>(4);

  final T value? 
  const Option([this.value]);
}

[munificent]

I'm going to close this out because there are already existing feature requires for sum types, pattern matching, and members inside enum types. In the future, if you have a language feature request, please write a detailed explanation for what problem you would like the language to solve and how you think it should solve it. Copy/pasting snippets of code from other languages does not tell us very much.