That error message isn't very good, but it's true that SomeClass & SomeProtocol doesn't have a representation compatible with T: SomeClass. In the former case, the details of how the type conforms to SomeProtocol need to be stored with the value, and the implementation of genericMethod won't have been compiled to do that. (@slavapestov, is that essentially correct?)

Keeping this open to improve the diagnostic (cc @xedin)

@swift-ci create

Comment by Tom Quist (JIRA)

@belkadan I'm not sure whether I could follow your explanation. From a type theory point of view "SomeClass & SomeProtocol" is a more concrete representation of "SomeClass" so I don't get why this is not be compatible with "T: SomeClass". Is this a technical limitation of the current implementation or am I missing something? Would that be something which could be made possible in future, e.g. by a swift-evolution proposal?

I picked the word "representation" carefully. SomeClass & SomeProtocol is a more specific type, yes, but it also requires two pointers' worth of storage rather than just one. I think it would be possible for the compiler to generate a wrapper function around genericMethod to handle this, but then we'd have a difference between generic functions (which can get this kind of wrapper) and generic types (which can't). Still, that could be worth it.

(Or we could give up the optimizations that rely on T: SomeClass being known to have a single pointer representation. I'm not sure if that's a realistic option, though—that is, I don't know how often these optimizations kick in.)