Aliases for enum members must be considered in exhaustive case

[straight-shoota]

When an enum contains aliases for a member, these aliases are currently required to be covered in exhaustive case:

enum Foo
  Bar
  Qux
  Baz = Qux
end
 
case Foo::Bar # Error: case is not exhaustive for enum Foo. Missing members: - Baz
in Foo::Bar
in Foo::Qux
end

This is rather inconvenient when Baz is an alias for Qux and both are supposed to be useable interchangeably.

A use case for this would be changing a member's name by adding a new member and keeping the old one as a deprecated alias (example: in #16354 we'd like to rename Redirect::Close to Redirect::Null).
The addition of an alias should not have an effect on exhaustive case behaviour.

There is a possibility that two members happen to share the same value, but are not exactly aliases. This could be the case for example when the values are defined externally, or may vary depending or depend on some configuration.
However, enums with flexible members are not relevant for exhaustive case, so it should be fine to ignore this. Just like we ignore arbitrary enum members like Foo.new(42) created at runtime.

---

Add a 👍 reaction to issues you find important.

[devnote-dev]

Maybe I'm misunderstanding something but I don't think this behaviour should be changed. While Baz is an alias, it's semantically equivalent to declaring it with the same value as Qux which would make sense to cover exhaustively. For specific migration/deprecation scenarios like #16354, I don't see what the benefit of this would be as opposed to just covering the member case as you normally would.

[straight-shoota]

The problem is not about another member which happens to have the same value, but a true alias. It's about adding another name for the same thing.

Let me demonstrate the problem:

The current definition of Process::Redirect is this:

 enum Redirect
  Pipe
  Close
  Inherit
end

Now we want to rename Close to Null because it's a better and correct name.
If we just replace Close with Null it would break a lot of code. That's impossible.

enum Redirect
  Pipe
  Null
  Inherit
end

So we'd like to introduce Null as an alternative name for Close and deprecate Close.
Old code expecting Close should continue to work and only produce a deprecation warning.

enum Redirect
  Pipe
  Null
  Close = Null
  Inherit
end

But when we introduce a new member Null, this break exhaustive case expressions. Legacy code cannot just continue to work with Close, it's forced to handle Null. Similarly, new or updated code cannot ignore Close.

So basically, right now, progressive enhancement is not possible. It's either staying with the current state or a hard break.

[straight-shoota]

Maybe we could use @[Deprecated] and @[Experimental] annotations as indicators for an alias vs. semantically different members with the same value?

[devnote-dev]

@straight-shoota Thank you for the clarification, this makes sense. 👍

[ysbaddaden]

While considering the @[Deprecated] annotation makes sense (in addition to be an alias), I think the pure alias is enough to consider that any of the constants must be defined for the exhaustive check to pass.

It's obvious, but the alias must refer to a constant of the same enum; neither of the following cases shall be considered pure aliases:

• alias FOO = EXTERNAL_CONSTANT
• alias FOO = LibC::ENUM_FOO
• alias FOO = OTHER_ENUM::FOO