[Proposal] Smart Enums In C# Like Java

[ProgrammingFire]

This proposal is about enums which is a pretty useful type in object-oriented programming but the thing that is missing from enum in C# is a feature from java that enums can be like classes a bit like they can have special properties, and have constructors and more...

An example for it will be a simple enum Subscription

In Java:

public enum Subscription {
    FREE("Free Tier", 0),
    PRIME("Premium Tier", 25),
    VIP("VIP Tier", 50);

    private final String name;
    private final String discount;

    public Subscription(String name, int discount) {
        this.name = name;
        this.discount = discount;
    }

    public String getName() {
        return this.name;
    }

    public int getDiscount() {
        return this.discount;
    }
}

In C#:

public enum Subscription {
    Free,
    Prime,
    Vip;
}

In C# I am not able to add constructors, properties, and methods. although there is a library to do this SmartEnum but wouldn't be nice if we have this feature built-in to C# where we could do something like this

public enum Subscription {
    Free("Free Tier", 0),
    Prime("Premium Tier", 25),
    Vip("VIP Tier", 50);

    private const string Name;
    private const int Discount;

    public Subscription(string name, int discount) {
        Name = name;
        Discount = discount;
    }

    public string GetName()
    {
        return Name;
    }

    public string GetDiscount()
    {
        return Discount;
    }
}

[brianebeling]

While I think that works and doesn't look half bad, what is the reason you cannot use a combination of a repository and an enum or any arbitrary value as key, that returns some record?
Why the record? Well, it's immutable and has value equality while being a reference type.

That could look like: var subscription = repository.Get(Subscriptions.Free) and then I can call all the methods you specified on my subscription record.

[HaloFour]

Oracles holds a patent on the implementation of enums in Java. IMO C# would do better to adopt Swift's version of enums instead which can also serve as discriminated unions.

[br3nt]

IMO C# would do better to adopt Swift's version of enums instead which can also serve as discriminated unions.

Swift's enum associated values concept is quite interesting indeed.
However, there is a key difference between associated enums and what @ProgrammingFire is requesting.

Swift's enums can be instantiated multiple times with associated values, whereas the enum in this proposal each enum has a single instantiation.

In theory, both could coexist together. That would actually be awesome if they did.

One place where they dont work together is enum flags.
Associated values dont work with enum flags as the api differs between enum values. A switch statement must be used access the associated values.
However, @ProgrammingFire's proposal does fit the concept of enum flags as each value implements the same api.

enum Barcode {
    case upc(Int, Int, Int, Int)
    case qrCode(String)
}

var productBarcode = Barcode.upc(8, 85909, 51226, 3)
productBarcode = .qrCode("ABCDEFGHIJKLMNOP") // associated values from upc(int, int, int, int) are overridden

You could merge both concepts by introducing a keyword to add associated values. For, example:

Associated values with normal enums:

public enum Shape {
    Square associate (double length),
    Rectangle associate (double width, double length),
    Circle associate (double radius),
}

Associated values with enum types:

public enum County {
    English("EN") associate (Word word, string singular, string plural),
    Hebrew("HE") associate (Word word, string singular, string dual, string plural),

    public const string Code;

    public Language(string code) => Code = code;
}

However, it might be better to separate the concept of associated values from enums and allow them to be associated with anything.

E.g

association SomeAssociation(string a, sting b);
association SomeOtherAssociation(int x, sting y);

enum Colour { Blue, Red, Green }

public void MyMethod() {
    var myString = "hello";
    var myStringWithAsscocitedValues = myString associate SomeAssociation("hello", "world")

   var red = Colour.Red;
   var redWithAsscocitedValues = red associate SomeAssociation("hot", "warning");
   var redWithOtherAsscocitedValues = red associate SomeOtherAssociation(1, "One");

  var someAssocitedValues = new[] { myStringWithAsscocitedValues, redWithAsscocitedValues };
  var a = someAssocitedValues.Select(v => v.a).ToList();
}

[HaloFour]

Swift's enums can be instantiated multiple times with associated values, whereas the enum in this proposal each enum has a single instantiation.

Any enum value that does not have associated data elements will also be a singleton. There's no reason to differentiate them into a completely different language feature.

[br3nt]

Any enum value that does not have associated data elements will also be a singleton

Of course. I was pointing out the case of associated values when used with [Flags]. Something like this, var barcodes = Barcode.upc(8, 85909, 51226, 3) | Barcode.upc(2, 66595, 11238, 7) | Barcode.qrCode("ABCDEFGHIJKLMNOP"), where the upc is set twice. But after seeing that code written, it might work just fine and be useful.

There's no reason to differentiate them into a completely different language feature.

I think I've demonstrated sufficiently that associated values are useful outside of the context of just enums in the last example of my previous comment. That's at least one reason.

I think we're discussing something off topic from this disucssion which should actually be about enum types. Are you able to open a new discussion for associated values? It'd be a cool feature.

[HaloFour]

@br3nt

I think we're discussing something off topic from this disucssion which should actually be about enum types. Are you able to open a new discussion for associated values? It'd be a cool feature.

Discriminated unions are also enum types and cover both this use case and many others. That's why Swift and other similar languages have the same syntax to declare both. That proposal is already championed and being actively explored by the language design team: #113.

[jstafford5380]

Oracles holds a patent on the implementation of enums in Java. IMO C# would do better to adopt Swift's version of enums instead which can also serve as discriminated unions.

Came here to say the same thing. Swift enums are pretty great

[bernd5]

Why not using a record?

E.g.:

using System;

var free = Subscription.FREE;
Console.WriteLine(free == Subscription.FREE);

public record struct Subscription {
    public static readonly Subscription FREE = new("Free Tier", 0);
    public static readonly Subscription PRIME = new("Premium Tier", 25);
    public static readonly Subscription VIP = new("VIP Tier", 50);
    
    public String Name { get; }
    public int Discount { get; }
    
    public Subscription(String name, int discount) {
        Name = name;
        Discount = discount;
    }
}

[pinkfloydx33]

If you go this route you can even use completionlist (a special xmldoc tag) to make the static fields/properties show up more like true enums in intellisense

[br3nt]

More work needs to be done to implement the functionality provided by enum flags. Operator overloading and returning a HashSet might be enough to provide this.

But how would you iterate over the defined values? E.g with enums we have Enum.GetValues(typeof(Colors))
Using records or some other existing language feature, the property/field/etc defining the enum value would always have to be defined at least twice: once when defining and a second time for use when enumerating.]
If a developer adds a new enum value, but forgets to add the second reference, the implementation breaks.

Besides, yes, there may be a way to get the requested functionality using existing code features, but that is not an argument to not consider the functionality requested by @ProgrammingFire. The request provides simplified syntax based on an implementation from another language for a proven and useful feature.

[br3nt]

@pinkfloydx33 can you link to docs on completionlist? I'm struggling to find how they should be used.

[Unknown6656]

@br3nt :

https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/may/documenting-your-code-with-xml-comments#:~:text=completionlist

[Mrxx99]

@Unknown6656 As I understand that article CompletionList is used to control which XML elements are suggested by intellisense in XML doc comments. So that is unrelated.

[ProgrammingFire]

Why not using a record?

E.g.:

using System;

var free = Subscription.FREE;
Console.WriteLine(free == Subscription.FREE);

public record struct Subscription {
    public static readonly Subscription FREE = new("Free Tier", 0);
    public static readonly Subscription PRIME = new("Premium Tier", 25);
    public static readonly Subscription VIP = new("VIP Tier", 50);
    
    public String Name { get; }
    public int Discount { get; }
    
    public Subscription(String name, int discount) {
        Name = name;
        Discount = discount;
    }
}

Enums Code Look More Clear And Readable In Comparison With Record Or Classes

[Aniobodo]

Unlike enum, record/struct cannot be a const!

[TahirAhmadov]

I doubt this Java style enum can be made constant, either, at least without a huge amount of work.

[warquys]

I don't remember having encountered const value in java. There is final however this is more akin to readlonly.

[ProgrammingFire]

While I think that works and doesn't look half bad, what is the reason you cannot use a combination of a repository and an enum or any arbitrary value as key, that returns some record. Why the record? Well, it's immutable and has value equality while being a reference type.

That could look like: var subscription = repository.Get(Subscriptions.Free) and then I can call all the method you specified on my subscription record.

You Could Do Something Like This But Now For One Feature, You Have Two Different Data Structures And You Need To Merge Which Is Kinda Bad For Clean And Clear Code.

[ufcpp]

US Patent

[Lmpessoa]

Just for the record, this link says the patent expired this year.

[brianebeling]

While I think that works and doesn't look half bad, what is the reason you cannot use a combination of a repository and an enum or any arbitrary value as key, that returns some record. Why the record? Well, it's immutable and has value equality while being a reference type.
That could look like: var subscription = repository.Get(Subscriptions.Free) and then I can call all the method you specified on my subscription record.

You Could Do Something Like This But Now For One Feature, You Have Two Different Data Structures And You Need To Merge Which Is Kinda Bad For Clean And Clear Code.

You are right, I was kinda planning ahead here. Ignore the repository, that is not relevant to your case. @bernd5 has a great and clean solution. If I was you I'd stick with that. In my opinion records are super clean and nice to work with.

[TahirAhmadov]

You can decorate the enum options with attributes, and write extension methods to get the values set in those attributes, as needed.

enum Color { [Name("Red")] Red }
public static class _Color_Extensions
{
  public static string? GetName(this Color This) => 
    typeof(Color).GetFields(BindingFlags.Public | BindingFlags.Static | BindingFlags.DeclaredOnly)
      .First(f=>f.Name == This.ToString())
      .GetCustomAttributes<NameAttribute>().FirstOrDefault()?.Name;

  static readonly string[] _names = new[] { "Red" }; // or use a cache
  static readonly string[] _names = Enum.GetValues(typeof(Color)).Select(...).ToArray(); // you can also populate from attributes, during static init
  public static string? GetName(this Color This) => _names[(int)This];
}

(The above code is un-tested - just wanted to give you an idea.)

[jnm2]

I'd recommend adding binding flags Public | Static | DeclaredOnly. Otherwise, it's not obvious whether an enum member named value__ would be found or confused with the public instance field.

[TahirAhmadov]

And I also fixed "right" to "write", hahaha

[ProgrammingFire]

But Now Have The Actual Enum + The Extensions Which Looks Not Good For Clean And Clear Code.

[Unknown6656]

While I also would like to see "smart" enums in C#, I'd like to ask: was it intentional that you opened the exact same issue/discussion two times?
See #5935

[ProgrammingFire]

It's just a mistake

[kumarc-123]

This is a much needed improvement to C#. Writing an extension class or record class/struct just to get properties and methods is a bad smell from a language perspective especially in 2023. We have modern languages that support a variety of language level features.

Can we get an update on what's happened to this proposal? Whether it's considered to be implemented in future versions or not?

Also, none of the reasons mentioned by commenters that are against this proposal work/justify why this is not needed in C#. C# as language still needs a lot of improvements and it doesn't need to stick onto older ways of coding.

Modern languages like Swift, Rust, Carbon, Kotlin are evolving and they have more developer friendly features. Hoping C# stands out as the best choice even in next 10 years.

[CyrusNajmabadi]

Can we get an update on what's happened to this proposal?

We automatically update proposals when things have changed with them. So if there have been no updates there are no changes currently.

Whether it's considered to be implemented in future versions or not?

Yes. Anything not explicitly marked as something we will not to is up for consideration for future versions of the language.

[CyrusNajmabadi]

justify why this is not needed in C#

Language design works the opposite direction here. It's not up for little to justify why something should not be done. Instead, those wanting the feature need to justify why it is important enough to do.

[Mrxx99]

Object enums, as described in this proposal, are patented by Oracle. Needed or not, that patent does weigh on what may be added to the language.

But it expires next year, so we'd just have to wait one more year

[HaloFour]

I thought that the EU patent extended longer. Either way, discriminated unions should be able to scratch the same itch while enabling more scenarios since they can carry additional data elements. Enums in Swift are discriminated unions and they have a very pleasant syntax.

[Mrxx99]

I thought that the EU patent extended longer.

Eu patent expires in 8 months: https://patents.google.com/patent/EP1400895B1/un

Don't want to argue against Discriminated Unions, just wanted to add the info

[Korporal]

This proposal is about enums which is a pretty useful type in object-oriented programming but the thing that is missing from enum in C# is a feature from java that enums can be like classes a bit like they can have special properties, and have constructors and more...

An example for it will be a simple enum Subscription

In Java:

public enum Subscription {
    FREE("Free Tier", 0),
    PRIME("Premium Tier", 25),
    VIP("VIP Tier", 50);

    private final String name;
    private final String discount;

    public Subscription(String name, int discount) {
        this.name = name;
        this.discount = discount;
    }

    public String getName() {
        return this.name;
    }

    public int getDiscount() {
        return this.discount;
    }
}

In C#:

public enum Subscription {
    Free,
    Prime,
    Vip;
}

In C# I am not able to add constructors, properties, and methods. although there is a library to do this SmartEnum but wouldn't be nice if we have this feature built-in to C# where we could do something like this

public enum Subscription {
    Free("Free Tier", 0),
    Prime("Premium Tier", 25),
    Vip("VIP Tier", 50);

    private const string Name;
    private const int Discount;

    public Subscription(string name, int discount) {
        Name = name;
        Discount = discount;
    }

    public string GetName()
    {
        return Name;
    }

    public string GetDiscount()
    {
        return Discount;
    }
}

What Java has was never an enumerated type, it was just called an enum but should have been called something else IMHO.

[Korporal]

which is why I wrote "IMHO".

Sure. But as this is an enumeration (which you agreed with)... enum seems very reasonable to use as the term for it. I'm not sure why java would be beholden to have hte exact same meaning for that keyword as other more limited languages. Any more than any new language being limited to how they use terms like namespace or interface because of how C# does it. The java concept is nice and useful, and the term they use is sensible and reasonable. IMO, it's reasonable for them to use it, and i'm not sure how critiquing their choice of a particular keyword choice helps this discussion out.

Once again, I said that IMHO a different term to enum would have been preferable, that's my opinion as I've said three times now.

[CyrusNajmabadi]

that's my opinion as I've said three times now.

@Korporal you are free to state your opinion. Others are free to respond in kind, including determining the value of those posts to this discussion as a whole. Thanks!

No one has stated you don't or can't have this opinion. Simply that from our perspective the naming is totally reasonable, which would similarly apply to any design work we do here.

[Korporal]

that's my opinion as I've said three times now.

@Korporal you are free to state your opinion. Others are free to respond in kind, including determining the value of those posts to this discussion as a whole. Thanks!

No one has stated you don't or can't have this opinion. Simply that from our perspective the naming is totally reasonable, which would similarly apply to any design work we do here.

First I never said that anyone has "stated" that I "don't or can't have this opinion" so that's a strawman argument. Second whether enum be reasonable or not is a matter of opinion and my opinion clearly differs from yours. Third by all means continue to respond I've not objected to you doing so.

[CyrusNajmabadi]

First I never said that anyone has "stated" that I "don't or can't have this opinion"

I didn't say anyone had. :-)

I just wanted to make it clear that wasn't happening and I didn't want any uncertainty from anyone that that's fine to state opinions.

Third by all means continue to respond I've not objected to you doing so.

Continuing to respond that this is simply your opinion isn't really necessary then. It's very very clear and no one is stating otherwise. :-)

What is being provided are the arguments for why it's fine for our language (which is similar to java). Keeping things on the topic of this proposal and the design aspects as it applies to c# would be great. Thanks!

If you just have an opinion (and nothing more) that that's not a good idea, that's fine. That opinion has been heard. If there's more to that opinion beyond what has been posted already (like that it just "should have been called something else"), that would be helpful. Thanks!

[bottle2]

the US patent expires next month!

currently I'm resorting to Joshua Bloch's "Typesafe Enum" design-pattern detailed in Item 21 of Effective Java, first edition.

in the meanwhile I'll explore C#'s Source Generators to relieve the insane boilerplate I currently have to maintain.

if anything similar is added to C#, it will finally achieve a fraction of expressiveness of X Macros from C/C++!!!

• https://en.wikipedia.org/wiki/X_macro

[KennethHoff]

With extensions maybe coming soon, you could presumably add many of these things (Properties, static methods, etc..) to an implicit extension to an Enum. Not perfect, but a practical "side effect" of the feature.