Very confused about some compiler warnings related to protocols—bugs or intended?

[xwu (Xiaodi Wu)]

@1oo7

I am not talking about a protocol type, I'm talking about an instance of a protocol type —which does, by definition, conform to that protocol.

I'm not sure what you mean here; only types conform to protocols, not instances.

@1oo7

No, but all of those can be accessed from an instance of a protocol type —to wit, the following compiles and runs just fine:

@1oo7

type(of: Bar().foo).perform()
type(of: Bar().foo).init(bar: 104)

The function type(of:) gives you the dynamic type of a value. This is distinct from the static type.

@1oo7

@itaiferber

The key here is that by design generics require static type information; dynamic type information (which is indeed provided at runtime) is insufficient.

I can see that there is a technical difference under the hood, regarding a difference between how existentials and generics are handled, with relation to vtable lookup.

The distinction between the dynamic type and the static type is not an "under the hood" matter. It is part of the user-facing semantics of Swift.

@1oo7

However lets look at what this means for Swift developers:

• cryptic, counter-intuitive, and often self-contradictory compiler warnings
• just resort to @objc and the problem goes away (but at what cost?)
• the only alternative seems to be kludgy type-erasure schemes
• so people just avoid adding Equatable or Hashable like the plague since it breaks everything

Seems to me, if we're going to be forced to resort to type-erasure anyway, couldn't the compiler just auto-synthesize the type erasure code behind the scenes? Would there be a drawback to that?

In the general case, it is impossible to conform every existential type to its own protocol automagically. This is not a limitation of Swift.

Consider the Comparable protocol:

You can conform type A to Comparable, providing an implementation such that (a1 < a2) == true. I can conform type B to Comparable, providing an implementation such that (b1 < b2) == true. However, if the existential type Comparable conforms to itself, then that implies we could write:

let a1c = a1 as Comparable
let b1c = b1 as Comparable
print(a1c < b1c)
// If Comparable conforms to itself, then we can compare the two values.
// But what is the result?

The compiler cannot pull an implementation of such an operation out of thin air. Yes, we can arbitrarily create a rule which sorts every value of type A before every value of type B by lexical ordering of type names, but someone would need to actually make that arbitrary decision and write it out in the form of a concrete implementation of static func < for the existential type.

(Then, someone else would complain that it would be a very silly implementation, because it would imply (100 as Int) < (0 as UInt); thereby demonstrating that any reasonable implementation requires specific knowledge of the semantics of the requirement being implemented as well as of any relationships among conforming types. You can peruse the multiple revisions of AnyHashable to see how difficult it is to implement a hash value that fulfills all the required semantics.)

The same applies to static methods, initializers, and Self or associated type requirements in every protocol.

Sure, we can (and eventually should, IMO) relax the rules around which protocols can be used as existential types, change the spelling of existential types from P to any P, and even allow users to implement self-conformance by writing extension any P: P { ... }, but the implementation itself (the part that's elided here with ...) will have to be manually written. There is no "auto-synthesis" here in the general case.