Add countof(SomeEnum) as a compile-time constant

[Entiat]

(I have zero doubt this has come up before, multiple times, I've searched but no luck - my apologies if the reason this was never implemented is "common knowledge" and I've just missed it)

There is currently no way to determine the count of an enumerated type as a compile-time constant. This means this count cannot be used in many useful scenarios, including default method parameter values, array sizes at compile time, and as attribute parameters.

Workarounds in wide use are klunky and error-prone.

Example of use:

public enum MyEnum
{
     FirstItem,
     SecondItem,
     ThirdItem
}

// Later...

[AttributeWithAnIntParameter(countof(MyEnum))]
public SomeMethod(int size = countof(MyEnum))
{
     // code that uses size...
}

Examples of a couple error-prone workarounds in current common usage:

public enum MyFirstEnum
{
     FirstItem,
     SecondItem,
     ThirdItem
}
public const int MyFirstEnumCount = 3;

// Some relevant static class somewhere
static RelevantClass()
{
    Debug.Assert(MyFirstEnumCount == Enum.GetNames(typeof(MyFirstEnum)).Length, "MyFirstEnumCount is out of sync with the actual count of enum items");
}

Or:

public enum MySecondEnum
{
     FirstItem,
     SecondItem = 42,
     ThirdItem = 0x1234,

     countof = 3
}

// Some relevant static class somewhere
static RelevantClass()
{
    Debug.Assert(MySecondEnum.count == Enum.GetNames(typeof(MySecondEnum)).Length, "MySecondEnum.countof value is out of sync with actual count of enum items");
}

[HaloFour]

A compile-time constant wouldn't work well if the enum was defined in another assembly and the number of items could change. Then then count would be wrong which could negatively affect code. Better to calculate the length once at runtime, which is cheap and has the advantage of being correct.

[Entiat]

Current use cases for me are twofold:

First, a type safe (ish) way to index arrays. For example, I am currently building out a marine mammal species name translation class that knows about common English, common Spanish, Latin (scienfitic), and a weird, archaic code system for marine mammals that some biologist invented when the dinosaurs roamed the earth...well, the 1970s :-) but is still in use by a few biologists today.

Since the numbers are relatively small (~130 marine mammal species) using an array of arrays works better (fewer bugs, my use case is fine with in-order traversal pattern matching) than more complex indexed/hashed data structures one might consider for general purpose translation APIs.

Anyways, the solution path I've chosen is to define an enum to facilitate language selection:

public enum Language : int
{
     CommonEnglish,
     CommonSpanish,
     Latin,
     KenneyCode,

     CountOf = 4
}

This then facilitates allocation of 2D arrays of names that can be iterated, translated, indexed via ToLower and a Dictionary if it becomes necessary, etc. Adding another language is a simple matter of adding it to the enum (and hopefully remembering to update CountOf) and then dealing with compilation errors because things break at compile time if I forgot to add something.

I understand there are runtime workarounds (for example: Enum.GetValues(type).Length in static constructors) for this and I use them. They are, however, a bit klunkier and require I never pass these lengths as default parameters to initialization methods. More importantly, instead of finding my own coding errors around these constructs at compile time, I (hopefully!) need to find them during runtime testing (Debug.Asserts everywhere) before shipping to my customers.

Second, Parameters for attributes. I've mentioned others out there using Unity's Range Attribute (search SO for examples) which takes integers and it can be useful to leverage the count of an enumerated type in certain circumstances. My use cases are similar, albeit relative to UI for recording data about marine life and my Attribute-derived classes want to know the count of an enum in a constructor parameter.

Similar problem space, with similar workarounds and similar (not horrifyingly bad, but still non-zero) increased bug risks - finding bugs is based on Debug.Assert and exceptions at runtime rather than compile-time errors.

---

As I said, this issue isn't the end of the world - but if it were implemented in a constrained way (literally just the count of items, maybe define it to match what Enum.GetValues(type).Length returns at runtime?) would be nice and could reduce the frequency of a certain set of bugs.

[CyrusNajmabadi]

First, a type safe (ish) way to index arrays

This use case makes sense. But in that case, the sensible operation to me is getting the max enum value. That way you can create an array one larger than that. Then you can index safely given any of the current values in the enum.

Similarly, an operation that does the same, but is the max flags value, again for indexing.

'Count' doesn't seem right here.

[CyrusNajmabadi]

I understand there are runtime workarounds (for example: Enum.GetValues(type).Length in static constructors) for this and I use them

Note: given your use cases, I don't view this as a workaround. It seems like the only viable path. This should not be a constant here. Otherwise, if you add a single member, your downstairs built binaries will break (since they will now allocate an array that is too small for the number of named enum members they can receive.

This is truly not a constant value, so even for your use cases you'd want and need this to be computed at runtime for correctness.

[mysticetus]

How is this different than deleting an enum value, which is also a breaking change for downstream dependent assemblies? Or any other breaking change (symbol name change, class declaration change, etc.)

These then cause the downstream assemblies to be rebuilt (if that's what you are doing), and if they reference the deleted enum a compiler error is generated. I'm not an expert on what happens to dependent assemblies if you don't rebuild them (I don't do that with my code) - but I assume there are versioning/hash/checksum checks in place to detect this and fail to load (or something?).

Is there a reason we can't do the same dependency-tracking and rebuild/error-on-load for countof()?

[CyrusNajmabadi]

How is this different than deleting an enum value, which is also a breaking change for downstream dependent assemblies? Or any other breaking change (symbol name change, class declaration change, etc.)

Because adding an enum value has never been a breaking change. It's different because it's not at all like any of those things.

[jnm2]

This is another case (similar to #8505, typeof string constants) where you can use a source generator today to declare the constant that you want to use.