Chapel: Should enums support `.indices` and indexing?

[bradcray]

Internally, Chapel uses a dense indexing scheme for enum symbols that is used to store and track them. Conversions between the indices and enum symbols and back again have been supported by undocumented routines and are useful when doing things like I/O or using implementing ranges of enums. This issue asks whether these indices should be exposed more directly to users as well. For example, imagine:

• proc type enum.indices: would return the legal set of indices for accessing an enum (say 0..#enum.size)
• proc type enum.this(i: integral): would return the i-th constant in the enumeration

Thus:

enum color = {red, green, blue};
writeln(color.indices);  // would write out `0..2`
writeln(color(1));       // would write out `green`

[ronawho]

Supporting direct indexing feels like it could get weird for enums with values. If you have something like:

enum day {monday=1, tuesday=2, ... sunday=7} 

what would you expect day[1] to be? (if you define it as dense 0-based indexing then tuesday, but I'm not sure what I would expect without looking at the docs)

---

For just color.indices I _think_ I would expect that to return an enum range and be red..blue instead of 0..2

[bradcray]

For just color.indices I think I would expect that to return an enum range and be red..blue instead of 0..2

That's an interesting proposal, thanks for pointing it out.

what would you expect day[1] to be?

I know what I'd expect it to be :), but I take your point that it could be confusing.

[bradcray]

Thinking about this for another day, I have a few thoughts:

• I'm not convinced .indices is the most accurate description of what red..blue is. For example, for a tuple (1, 2, 3), the indices are 0..2 and the values are arguably 1..3. Similarly for a string "hi", the indices are 0..1 and the values are arguably "h", "i". For an enum, my intuition is that red..blue is more about the values of the enum rather than its indices.

• That said, we could also think of red..blue as the indices and their numeric values their values, in the event that they had numeric values (I think I've gotten onto the "nice tuples don't need user-defined integer values" train, which is why this is the secondary rather than primary thought for me). And maybe it's more beneficial to create something that's useful / helpful than that is pure (by some definition of "pure").

• That said, I do think we need some user-facing way to get at the underlying 0, 1, 2, 3... values of enums for people who want to write more serious stuff with enums (the kind of stuff that's currently baked into the compiler and our internal modules). So we don't support that in this way, we should come up with some other proposal for it (and I think we should probably come up with that way before deciding what .indices means on an enum.