3 ms·

I wonder if this behavior is working as intended. It does look like a bug to the language itself, isn't?

mgoblu3 8y ago
There are some rules around this, as noted in https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future: 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.
anon180719 8y ago
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.
- joeblau 8y ago
  > It appears the correct action would have been to use <code>override func greet() { print("sup") }</code>. That actually doesn't work because the greet function is implemented on an extension. You can only override class functions.
  - anon180719 8y ago
    Oh, that's definitely weird then. Is there an RFC to have that fixed in some way?
    - joeblau 8y ago
      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.
      - anon180719 8y ago
        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.
      - slavapestov 8y ago
        It's a bug - https://bugs.swift.org/browse/SR-103 https://bugs.swift.org/browse/SR-103

There are some rules around this, as noted in https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future: 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.

anon180719 8y ago

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.

joeblau 8y ago
> It appears the correct action would have been to use <code>override func greet() { print("sup") }</code>. That actually doesn't work because the greet function is implemented on an extension. You can only override class functions.
- anon180719 8y ago
  Oh, that's definitely weird then. Is there an RFC to have that fixed in some way?
  - joeblau 8y ago
    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.
    - anon180719 8y ago
      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.
    - slavapestov 8y ago
      It's a bug - https://bugs.swift.org/browse/SR-103 https://bugs.swift.org/browse/SR-103