self in a Swift Self-executing Anonymous Closure
Conclusion:
selfwas justnilthe whole time! What a goofy mistake! […] However, that was not the case. Specifically,selfwas notnil. Not only that, butselfwasn’t theselfI expected.[…]
Second, why is
selfan instance of(MyTableCell) -> () -> MyTableCelland not() -> UIButton?[…]
If you declare
buttonaslazy varinstead oflet, then the expected behavior occurs. That is,selfis an instance ofMyTableCellwithin the self-executing anonymous closure and the call toaddTarget(_:, action:, for:)works.[…]
The type of
selfresolving to(MyTableCell) -> () -> MyTableCellis the unfortunate result of theNSObjectinstance method-[NSObject self]and Swift’s curried functions.[…]
Correcting the expression
self(without backticks) to reference the enclosing type introduces another interesting question: what should be order of operations during initialization? When usinglet, the property is initialized before the enclosing type. When usinglazy var, the property is initialized after the enclosing type. I am not a compiler expert, so I will not attempt to answer which is better. But if initialization order cannot be changed in the compiler to fix this, then I think the expected behavior would be to produce the same error as non-NSObjectclasses: “Cannot find ‘self’ in scope”.
Previously:
- Using Lazy Variables to Work Around Swift Initialization Rules
- Swift init()
- Strange Tales of Swift Initialization
