Ergonomics: generic types conforming "in more than one way"

[dabrahams (Dave Abrahams)]

Responding to @Paul_Cantrell's post from another thread here, because it's really this topic IMO:

@Paul_Cantrell

In Dave’s example in that second link, this dynamically dispatched code:

extension P {
    static var isEquatable: Bool { false }
}

…is something that the value itself knows — “I am not equatable” — whereas this statically dispatched code (which if I understand correctly is a shadow, not an override):

extension P where Self : Equatable {
    static var isEquatable: Bool { true }
}

…is tied to something the calling context knows — “if you think I implement the Equatable protocol, then I guess I’m equatable!” Dave’s example goes haywire because the local assumptions (the static types) that could expose this isEquatable implementation don’t travel around with the value itself.

It's much worse than that, unfortunately. Whether that second extension acts as a shadow or an override depends on the concrete type it applies to:

struct X : P, Equatable {...} // override
struct Y<T> : P, Equatable { ... } // override
struct Z<T> : P {}
extension Z : Equatable where T: SomeProtocol { ... } // shadow!

@Paul_Cantrell

Back to the problem at hand: I don’t think you can get things to make sense again here without doing some kind of runtime test based on metadata that lives with the value itself. Whether that’s an expensive type metadata search with is or the vtable lookup I sketched, it has to be dynamic.

I don't want to disagree exactly, but I'd like to draw a distinction between programs that are semantically static and those that are semantically dynamic, because that's an entirely different question than whether the program happens to be implemented using dynamic dispatching. A semantically static program is one in which, if the whole program is visible to the compiler, all dynamic dispatching based on types could be optimized away by specialization. ¹

In Swift, all unoptimized generic code is implemented with dynamic dispatching, but the code is semantically static as long as no existentials or non-final classes (the basic type-erasing mechanisms) are involved. ² (at the point where these erased types are created the semantically static information is captured and, as you say, “lives with the value itself”). IMO it's hugely valuable that generic code is always semantically static, and the semantics I have in mind for getting “this to make sense” preserve that property.

---

¹ I invented these terms AFAIK; if there are established words for this distinction, let's use those instead.
² Closures with captures can be viewed as another type erasing mechanism. I'm not overlooking those, and if you want to fold them into this discussion, we can, but it will complicate things.