I can't be 100% positive, but here's what I believe is happening:
Protocol extensions aren't accessible from ObjC
. Since UITextFieldDelegate
is an ObjC
protocol, its reliant on ObjC
dispatching. As far as the compiler is concerned, the methods in your default implementation are inaccessible, even though they do exist.
To clarify, we can extend these protocols if its truly an extension and adds behavior. This behavior will only be accessible in Swift and shouldn't be problematic in any way.
The problem is default implementations not being ObjC
accessible.
Here's a quick example of a custom version:
@objc protocol Test : class {
func someFunc() -> String
}
extension Test {
func someFunc() -> String {
return ""
}
}
// Fails here 'candidate is not @objc but protocol requires it`
class Hi : NSObject, Test {
}
Xcode suggests appending @objc
but it will keep suggesting this over and over again until you get @objc @objc @objc Hi : ...
Based on our conversation below, I made this which seems to be working. I can't fully explain why yet:
@objc public protocol Toto: UITextFieldDelegate {
optional func randomInt() -> Int
}
extension Toto {
func randomInt() -> Int {
return 0
}
func textFieldShouldReturn(textField: UITextField) -> Bool {
return false
}
}
class Tata: NSObject, Toto {
}
Ok, I realize that I'm considering a different problem, and while this compiles, it won't work, and the issue is dynamic dispatch. If you try to append your method w/ @objc
, or dynamic
, the compiler will warn you that you can't dispatch this way, except on classes. Since a protocol exception doesn't conform to this, when ObjC dispatches the message send, it can't find the implementation in your extension.
Since Swift is constantly updating, here's when this answer was applicable:
Swift 2.0 Xcode 7 GM
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…