I have the following class hierarchy:
class ScrollableViewController: UIViewController, UITableViewDelegate { // ... }
That implements one
tl;dr you need to prefix the function declaration with its Objective-C declaration, e.g.
@objc(tableView:heightForRowAtIndexPath:)
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
// return stuff
}
I was tipped off to this being a solution thanks to the Swift 3 Migration Guide which states:
If you implement an optional Objective-C protocol requirement in a subclass of a class that declares conformance, you’ll see a warning, “Instance method ‘…’ nearly matches optional requirement ‘…’ of protocol ‘…’”
• Workaround: Add an
@objc(objectiveC:name:)
attribute before the implementation of the optional requirement with the original Objective-C selector inside.
I'm fairly certain this is a bug: it appears that the the runtime dynamism that allows checking for selector capability does not get properly bridged in the Grand Swift Renaming when the protocol method is in the subclass. Prefixing the function declaration with the Objective-C name properly bridges the Swift to Objective-C and allows Swift 3 renamed methods to be queried with canPerformAction:withSender:
from within Objective-C
This appears to be fixed in Swift 3.0.1 for normal subclasses, but is not fixed for generic subclasses:
class A: NSObject, UITableViewDelegate {}
class B: A {
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {}
}
class C<T>: A {
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {}
}
print(#selector(B.tableView(_:didSelectRowAt:))) // tableView:didSelectRowAtIndexPath:
print(#selector(C<Int>.tableView(_:didSelectRowAt:))) // tableView:didSelectRowAt:
See: https://bugs.swift.org/browse/SR-2817
To fix it: https://stackoverflow.com/a/39416386/1109892
@objc(tableView:heightForRowAtIndexPath:)
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
// return stuff
}