Hacker News new | ask | show | jobs
by anon180719 2879 days 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.

1 comments

> 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.

Oh, that's definitely weird then. Is there an RFC to have that fixed in some way?
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.