This shocked me!

Using Swift
#1 
//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?

#2

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.

#3

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)
}
4 Likes
#4

@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 https://bugs.swift.org :)

1 Like
#5

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])
}
#6

There are several compiler bugs around common base names; SE-0155 is not fully implemented. For example: https://bugs.swift.org/browse/SR-12229 and https://bugs.swift.org/browse/SR-9014.

2 Likes
#7

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.

#8

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🤞

5 Likes