This shocked me!

//Suppose you have an enum like this:
enum MessageType {
   case request(string: String)
   case request(double: Double)

//make an instance
var a = MessageType.request(double: 0.1)

//here comes the fun part: match it!
//it seems like it cannot do it 
//because the compiler says that the second case is already handled 
//by the first one
switch a {
   case let .request(string): print(string)
   case let .request(double): print(double)

Does this mean that even though it is possible to declare two cases with the same names, but different signatures, it is not possible to match them? What am I doing wrong, if that is not the case?

Yep, that's a bug or undefined behavior. The warning should be suppressed .
You can even declare an Enum as

enum MessageType {
   case request(label: T)
   case request(anotherLabel: T)

Swift treat them as different case patterns.

I'm pretty sure that's reasonably ambiguous as nothing tells the compiler what's different about the string and double variable bindings. Try adding type annotations:

switch a {
   case let .request(string as String): print(string)
   case let .request(double as Double): print(double)

@total_swiftification Yes that seems like a bug in memberLookup, where seems like is failing to match the declarations for the "ambiguous" case. I would suggest create a ticket on :)

1 Like

I asked about this here. The answer I got was:

From SE-0155:

Enum cases should have distinct full names. Therefore, shared base name will be allowed:

enum SyntaxTree {
    case type(variables: [TypeVariable])
    case type(instantiated: [Type])

There are several compiler bugs around common base names; SE-0155 is not fully implemented. For example: [SR-12229] Assertion failure when trying to pattern match enum cases with same base name · Issue #54655 · apple/swift · GitHub and [SR-9014] Pattern matching doesn't work for overloaded enum cases · Issue #51517 · apple/swift · GitHub.


Oh my, the oldest report of that issue happened in 2018th. Maybe after waiting for 2 more years this 'omissible' problem will happen to have its resolution.

SR-12206 should be fixed by my PR very soon (i just need to figure out this one last thing), after that I can take a look at SR-12229. I’m hoping to get SE-0155 fully implemented within the next few months🤞