Explicit ordering of multiple conditional conformances

[huon (Huon Wilson)]

@r-peck

I'm not certain what the additional overhead to checking conformance of concrete types in where clauses would be, but that might be a way forward.

Yeah, that definitely covers some cases (I'd guess most cases, in fact), but doesn't work when the type is an implementation detail/isn't meant to be part of the public API of code, e.g.

internal struct SomethingSpecial<T> { var x: T }

extension SomethingSpecial: P where T: Q {} else where T: R {}

public func doIt<T>(input: T) {
     let value = SomethingSpecial<T>(x: input);
     operation(value as P)
}

@r-peck

if T also happened to be Equatable , the first branch in the conformance chain would be followed in calls to == .

That doesn't quite match with Swift's behaviour elsewhere. Except for classes, choosing method overloads on concrete types is done with the static information available, and there's no dynamic dispatch. For instance:

struct X<T> {}

extension X {
    func foo() { print("no constraints") }
}
extension X where T == Int {
    func foo() { print("T == Int") }
}

// concrete
X<Int>().foo()
// generic
func callFooGenerically<T>(_: T.Type) { X<T>().foo() }
callFooGenerically(Int.self)