Pattern matching similar enum cases seems broken

[xwu (Xiaodi Wu)]

Here's, I think, the relevant core team message on the topic:

@Joe_Groff

SE-0155 Normalize Enum Case Representation

This proposal changes the behavior of enum case declarations to make their behavior more uniform with function and property declarations. Similar to what SE-0110 established for function types, SE-0155 makes an enum with a compound associated value like case foo(bar: Int, bas: Int) be treated as having multiple formal arguments instead of one tuple payload, with the argument labels becoming part of the case's formal name and the arguments themselves supporting default arguments and the other functionality of function declarations. As of Swift 5.2, the declaration and case construction functionality has been mostly implemented; case declarations can be declared with a common base name but different argument labels, can have default arguments, and can be applied and referenced like labeled function declarations. However, there are outstanding bugs when trying to actually use an enum with multiple cases that share a base name:

Issues · apple/swift-issues · GitHub Symbol collision when multiple enum cases with same base name have default arguments
Issues · apple/swift-issues · GitHub Assertion failure when trying to pattern match enum cases with same base name

Furthermore, none of the proposal's changes to pattern matching behavior have been implemented. Patterns are still allowed to match a compound associated value as a single tuple, and arbitrarily drop or include argument labels:

enum Foo { case foo(bar: Int, bas: Int) }

switch foo {
case .foo(let all): // still accepted
case .foo(bar: let x, let y): // still accepted
case .foo(let x, bas: let y): // still accepted
}

Although unfortunate, the Core Team does not consider it worth breaking source compatibility to change this behavior. Therefore, the pattern matching part of the proposal has been downscoped to allow for disambiguation when multiple cases share a base name, without changing the behavior for existing enums supported today. The remaining missing functionality should be implementable without breaking source or ABI compatibility. Because of the incomplete implementation, I have left the revised proposal in the "Accepted" state with the two bug reports above attached. If any implementation work does end up requiring breaking source compatibility, or if we decide to pursue other source-breaking changes to enum declaration or pattern matching behavior, we should do so in new proposals.