A generic function only gets one implementation (unlike, say, a C++ template), which is then used no matter argument you pass to it. That means it has to call the most general implementation of your properties. The only ways to get type-based dispatch in Swift are (1) classes and overriding, (2) calling a protocol requirement, or (3) explicitly checking types with as?.

Comment by André Pacheco Neves (JIRA)

Thanks for the quick reply!

I see... So in this particular case I would be forced to override the subclass' method to have the behavior I expect (1)? Because I think I am already using (2), but there are two competing implementations of the same requirement. Explicitly checking with `as?` is not very ideal too, as it doesn't "scale" very well.

Even in the override scenario It's really awkward to not be able to have the "free" implementation given by the extension.

Don't you think it's weird for users to have two distinct behaviors to what intuitively should be the same one? Shouldn't the compiler also infer the most constrained implementation when "choosing" which one to use?

It's tricky here because the compiler has to choose how to satisfy a protocol requirement at the time you declare the conformance. That's a property of SomeClass that isn't revisited for SubClass. You're right that the compiler could revisit this decision at that point, but that could lead to strange behavior if SomeClass and SubClass are in different libraries. (SomeClass adds a conformance to D, but SubClass isn't recompiled, so it gets the same behavior as the base class. If SubClass is later recompiled, that behavior will change.)

Comment by André Pacheco Neves (JIRA)

— It's tricky here because the compiler has to choose how to satisfy a protocol requirement at the time you declare the conformance

Why isn't it the same for both scenarios, since the conformance is clearly declared and it works as "expected" when invoked directly on a concrete type? I don't get why the generic "resolution" doesn't follow the same decision flow as when invoked directly. Doesn't the compiler have the same information available? It appears as if the compiler only checks the first node on the hierarchy (the super class), but stops there when evaluating the implementation to use.

— You're right that the compiler could revisit this decision at that point, but that could lead to strange behavior if SomeClass and SubClass are in different libraries. (SomeClass adds a conformance to D, but SubClass isn't recompiled, so it gets the same behavior as the base class. If SubClass is later recompiled, that behavior will change.)

My compiler knowledge is obviously limited (and sorry for that 😛), but in the above case, how does it behave if we simply invoke makeValue directly on an instance? Does it not face the same challenge?

Sorry for being persistent, but I am struggling to understand why this is not an issue. It honestly seems to me that this (unexpected) behavior will inevitably lead to situations where developers (like me) are caught by surprise when they discover which implementation has actually been chosen by the compiler (which is both unintuitive and poorly documented). As a language user I expect the compiler to choose how to satisfy a protocol requirement in a "consistent" way, unless explicitly instructed otherwise (e.g forcing as?), which isn't happening.

Thank you for your patience 🙂

Asking questions is always good!

The rule effectively is the same: choose what to use at the point you use it. In your example, the difference is the point of use:

1. class SomeClass: D & B is a point-of-use for "anything needed for SomeClass to conform to D" and "anything needed for SomeClass to conform to B", so we pick the best value and makeValue available to SomeClass. That's going to be its own value (which may be overridden), and the D where Self: B version of makeValue. This gets recorded in "how SomeClass conforms to D" and "B".

2. class SubClass: SomeClass & C is a point-of-use for "anything needed for SubClass to conform to C", so we pick the best modify available to SubClass. That's its own modify (there aren't any others). This gets recorded in "how SubClass conforms to C".

3. class AnotherClass: D & B & C is a point-of-use for "anything needed for AnotherClass to conform to D" and "B" and "C", so we pick the best value, modify, and makeValue available to AnotherClass. That's its own value and modify and the D where Self: B & C version of makeValue.

4. struct SomeStruct: D & B & C is the same as AnotherClass, really.

Okay, that's it for the conformances. Now we're at the concrete calls.

5. SomeClass().makeValue() is a point-of-use for "find a makeValue on SomeClass", and so it looks for the best makeValue available to SomeClass. This is the same decision made in (1), so we get the same answer: the D where Self: B version of makeValue.

6. SubClass().makeValue(), AnotherClass().makeValue(), and SomeStruct().makeValue() all work the same way: they have exactly as much information as 2-4, and so they pick the same overload of makeValue.

7. foo.makeValue() inside invokeMakeValue<F: D> is also a point-of-use, but not exactly an interesting one. All we know about foo is that its type conforms to D, and so the only choice is to call the requirement in the protocol…however that's been implemented.

8. invokeMakeValue(on: SomeClass()) is not a point-of-use for makeValue. Instead, it asks "how does SomeClass conform to D?" and passes that information to invokeMakeValue. The answer is what we picked in (1).

9. Similarly, invokeMakeValue(on: SubClass()) is also not a point-of-use for makeValue; it asks "how does SubClass conform to D?" The answer is "via its superclass, SomeClass", and therefore we get the same behavior as in (1). But with the overridden value.

10. invokeMakeValue(on: AnotherClass()) and invokeMakeValue(on: SomeStruct()) give us the same answers as (3) and (4), because they both conform to D directly.

Whew.

So, what would it take to change this behavior? It would have to be at step 2: when subclassing SomeClass, recheck the conformance to D and realize that there's now a "better" overload of makeValue() available. If D is a private protocol, rechecking that conformance for SubClass may not even be possible.

I hope this is a suitable explanation, if not necessarily as satisfying as you might like!

Comment by André Pacheco Neves (JIRA)

Wow, thanks for the great explanation @belkadan, It's now much clearer in my head (and I will certainly come back here if I hit this again 😃).

You're right it's not the outcome I would've hoped for, but I now understand better why this is working as intended. Who knows, maybe in the future that extra recheck step is added to subclasses and this stops happening? 😛

Thanks once again, and please keep being awesome!