Is it possible to augment the values of an enum?

[eernstg]

Thanks to @sgrekhov for bringing up this topic. We may or may not allow developers to augment an implicitly induced member like the values list of an enum:

enum E { one }

const someAnnotation = 1;

augment enum E {
  augment one;

  @someAnnotation
  augment static const values;
}

We do already allow the implicitly induced getter of an instance variable to be augmented, which may be seen as prior art. However, there may also be unwanted consequences of allowing augmentation of values.

(Note that the example relies on having #4008 such that augment static const values; isn't a syntax error.)

As @jakemac53 mentioned below, we could make augmentations of index, hashCode, and operator == an error as well. This may be covered already, otherwise we could add a couple of words in the augmentations feature specification in order to make it explicit.

name might have some restrictions as well, but this is an extension method and there is nothing stopping us from declaring a member named name in an enum, so we probably can't do anything about that.

@dart-lang/language-team, WDYT?

[jakemac53]

We probably should not allow augmenting values for enums.

[jakemac53]

We currently have this specified in the enhanced enums spec which I think probably covers this?

"It's a compile-time error if the enum declaration contains a static or instance member declaration with the name values, or if the superclass or any superinterface of the enum declaration has an interface member named values. A values static constant member will be provided for the class, this restriction ensures that there is no conflict with that declaration."

An augmenting declaration is still a declaration, so I think it is covered.

[lrhn]

We could allow augmenting the provided values declaration, like any other static constant variable declaration.
(Do we allow augmenting constant variables? I assume we do not allow augmenting their getter, but we should make sure to say that. So it can only be the initializer. Not impossible. Maybe confusing.)
Let's say we do not allow augmenting values with a new body (adding annotations is fine), then we can say that an augmenting enum declaration that adds enum values (which I think we do allow) implicitly "augments" the values declaration as if by

  augment static const List<ThisEnum> values =
      [...augmented, newValue1, newValue2];

If we did allow augmenting, we'd need to be careful about the specification of that values, so that the initial initializer existing contains all values declared by all later augmentations. Probably not impossible, but slightly harder to specify than an iterative process.

On a similar note: can you augment the getter for the representation value of an extension type with a new body? It's just a getter, but we special-case it to be promotable, which needs to be disabled if you augment with another getter body. Which is a property that isn't visible in the initial declaration, so it would be consistent to disallow augmenting it, because doing so changes the capabilities expected from the original declaration in a breaking way.
(Again augmenting without a new body shouldn't be a problem.)

[eernstg]

Sounds good! I'd prefer if we make it an error to augment the values of an enumerated type. We may then add support for doing it in the future, if someone comes up with a really compelling reason.

[jakemac53]

Should we similarly block augmenting the index, hashCode, and name?

[jakemac53]

Actually, it looks like index and hashCode are effectively blocked already, we don't allow members by those names in enums at all.

For name it is an extension getter technically, so you are allowed to generally create a member with that name, even though it is pretty weird to do so. But, I guess you should be able to augment it too then.

[eernstg]

Created #4103 to do this. It does not introduce any constraints on enum members whose name is name, because that would be a breaking change.