It appears the correct action would have been to use <code>override func greet() {
print("sup")
}</code>.
To be fair, I was primed to really think about the code execution given he'd indicated there was a trap in there somewhere, so it certainly would not have been immediately obvious on first glance. But I think, generally developers understand that <code>override</code> is necessary to override code from a parent class.
Typically XCode helps out with this sort of thing – adding <code>override</code> where it seems like it should be added – but perhaps not when a parent class is using a default protocol implementation.
But again, in this scenario where a class is inheriting from another class, it's typically known you need to override the function in order to use your own implementation, so this does seem a bit contrived.
I don't think there is. I think the code is functioning as expected — it's just written in a super confusing way. What should probably happen is that the compiler should throw an error about redefining a function in a super classes extension. I'm not a compiler engineer but a check for that seems like it would be intensive unless that information is codified in the AST somehow.
hmph. I agree, the compiler should probably not let you compile in that case. Funny enough this reminds me of "responder chain politics" in dynamically typed languages with duck typing.
IF the inferred type of a variable is the protocol:
AND the method is defined in the original protocol
THEN the runtime type’s implementation is called, irrespective of whether there is a default implementation in the extension.
AND the method is not defined in the original protocol,
THEN the default implementation is called.
ELSE IF the inferred type of the variable is the type
THEN the type’s implementation is called.
