CODEWITHSUNDEEP
swiftgenericsconstraintsoverloading
Trevor Thoele
Trevor Thoele

Reputation: 21

Why does the generic type not participate in method overloading via constraint further down the call chain?

Swift allows generic methods to be overloaded by the constraints placed upon the generic types passed in. If you use this with concrete types, then the type passed in will participate in this overloading and constraints will be inferred from that type.

As soon as a generic method delegates to another with overload resolution, the constraints can no longer be inferred and will instead utilize the constraints already placed on the type from above.

protocol Conformance {}

extension String : Conformance {}

// #1
func baseMethod<T>(_ value: T) {
    let isConforming = T.self is Conformance.Type
}

// #2
func baseMethod<T>(_ value: T) where T : Conformance {
    let isConforming = T.self is Conformance.Type
}

func delegatingMethod<T>(_ value: T) {
    baseMethod(value)
}

func run() {
    // Calls #2, isConforming = true
    baseMethod(String())
    // Calls #1, isConforming = true
    delegatingMethod(String())
}

I assume this is there so that you have sufficient type information from the call site about what constraints are applicable no matter where the generic type is used, but it seems to severely and artificially limit the utility of overloading by constraint.

Are there any known workarounds to this oddity? Something that emulates this would be extremely useful.

Upvotes: 2

Views: 294

Answers (1)

Rob Napier
Rob Napier

Reputation: 299345

Swift allows generic methods to be overloaded by the constraints placed upon the generic types passed in.

Yes...but be very clear that this is a static overload, not a dynamic override. It is based on types that can be proven at compile-time.

func delegatingMethod<T>(_ value: T) {
    baseMethod(value)
}

We're compiling this now, and we need to write it as a concrete, static function call, possibly inlined, into the binary. What do we know about T? We know nothing about T, so any where clause will fail.

We don't even know about how this function is called, because the call may come from another compile unit or module. While in principle, it could have different semantics based on access level, such that one version were used when it is private and all calls can be evaluated, and another used when it's public, that would be a really horrible source of bugs.

What you're asking for is that delegatingMethod defer its decision about what function call to make until runtime. That's not how generics work. Moreover, you're asking that all the where clauses be encoded somewhere in the binary so that they can be evaluated at runtime. Also not how generics work. That would require a much more dynamic dispatch system than Swift wants to implement. It's not impossible; it's just a completely different animal, and prevents lots of optimizations.

This feels like you're trying to reinvent class inheritance with protocols and generics. You can't. They're different solutions and have different features. Class inheritance is fundamentally dynamic. Protocols and generics are fundamentally static. If you want dynamic dispatch based on specific types, use classes.

Upvotes: 3

Related Questions