Comment by Daniel Jalkut (JIRA)

I am working around the issue in my Swift code by checking whether the superclass's instances respond to the selector, rather querying super directly:

if let superClass = self.superclass as? NSObject.Type {
    if superClass.instancesRespond(to: #selector(NSApplicationDelegate.applicationWillTerminate(_:))) {
        super.applicationWillTerminate(notification)
    }
}

Hmm. This used to go the other way, but I don't remember why we changed it. (Nor did we close the bug that was tracking the old behavior, rdar://problem/16127954.) @DougGregor, do you have the context here?

Comment by Daniel Jalkut (JIRA)

I feel like there are still some surprising behaviors here, but FWIW I guess I overlooked some nuances about the behavior of "respondsToSelector". The documentation indicates I should always be calling "instancesRespondToSelector" when checking super for conformance.

This appears to be a special case of a bug I just filed (SR-7067) wherein it seems that the Swift compiler simply assumes that an Obj-C class implements all optional methods of protocols it conforms to.

That said, you absolutely do need to still provide override when implementing the methods yourself, because you can't know at compile-time if the superclass implements it. However, ideally the Swift compiler would allow you to (nay, require you to¹) say something like super.someMethod?() to invoke it, though unfortunately the Obj-C runtime doesn't actually have a way to do this (the best you can do is query the superclass type if instancesRespondToSelector, but that doesn't help if the method is implemented dynamically at runtime, though it's certainly a lot better than not supporting this at all and requiring the subclass implementor to have to know whether it's safe to call super).

¹I don't know when optional protocol methods changed from optionals to IUOs, but because of that, you can call such methods without checking for their existence. This seems like a really bad idea to me.

@swift-ci create

Okay, it looks like this is not a recent regression, but more likely a deliberate "least bad choice" from a past release to deal with wanting to call super (as Kevin noted) that for some reason neither I nor Doug remember doing. We could still improve this situation, but at least it's understood.

(Optional protocol methods are not IUOs, as discussed elsewhere. That's a code completion bug.)