[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

More information about the swift-evolution mailing list