[swift-evolution] [Draft] Allow declaration of abstract functions and properties on classes
Brent Royal-Gordon
brent at architechies.com
Thu Feb 25 15:03:08 CST 2016
> How can the compiler enforce that the developer supplies a delegate?
By making the delegate/closure property non-optional, the compiler can ensure that there is always a valid delegate/closure set. The property would have to be initialized, so presumably the initializer would have to take the delegate/closure as a parameter.
(If you're willing to accept a little less compile-time safety to get more convenience, the property could be either an implicitly unwrapped optional or be marked @deferred using the upcoming behaviors feature. That would, for instance, make it possible to set this up entirely in Interface Builder without making a subclass just to override the initializer.)
> Show me how to do that in a way that enforces the developer supply an implementation. I don't see how it can be done, and if it can, it's certainly going to be far more convoluted than an abstract class.
I showed an outline of it a couple paragraphs down:
> protocol ActivityViewControlling: class {
> func retrieveText() -> String
> }
> extension ActivityViewControlling where Self: UIViewController {
> ...
> }
> class MyActivityViewController: UIViewController, ActivityViewControlling {
> func retrieveText() -> String { ... }
> }
`MyActivityViewController` *must* implement `retrieveText()` if it wants to conform to `ActivityViewControlling`.
You're right that this is currently somewhat convoluted (and someone else mentioned that the extension members may not override the inherited ones, which is obviously another problem). But I think protocols are actually pretty close to what you want already, and we're better off extending them to cover abstract class use cases than extending classes.
--
Brent Royal-Gordon
Architechies
More information about the swift-evolution
mailing list