[swift-evolution] Abstract methods

Slava Pestov spestov at apple.com
Sat Nov 4 00:24:32 CDT 2017



> On Nov 2, 2017, at 8:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Swift architectures use much less inheritance (and class types) in general than equivalent c++ architectures. personally i have never been in a situation where i didn’t need a pure abstract method that was better declared as a protocol requirement.
> 
> 
> I think we should beef up protocols a little bit so that they can serve the role of abstract classes. That would make for a nice, clean separation: anything abstract is a protocol, while anything concrete is a class (or struct or enum).
> 
> What would protocols need in order to support everything abstract classes can do? First, we'd probably need to extend class constraints to allow a protocol to require you to subclass a given base class:
> 
> 	// Hypothetical replacement for UIControl.
> 	protocol UIControl: UIView {
> 		func sendAction(_ action: Selector, to target: Any?, for event: UIEvent)
> 	}

This is planned, and in fact was part of the “subclass existentials” proposal that was otherwise implemented in Swift 4. The absence of this feature should be considered a bug, and something I’d like to fix eventually.

> Maybe allow them to declare automatically-added storage, perhaps even private to the protocol:

I’m not sure this really fits with the conceptual model of what a protocol is. Protocols define requirements, they don’t “add” things to the conforming type. It seems that allowing protocols to declare stored properties would bring many of the complications of multiple inheritance from an implementation standpoint. Also how would retroactive conformance work? Would you just be able to change the size of any public type in any other framework? This would have major implications for code generation and the optimizer.

In general I’m not convinced this is a useful feature.

> Probably something like `super` for when you want to override a default implementation but still call it:

This is a good idea. I think it would be pretty straightforward to implement, and it’s something that keeps coming up. We haven’t come up with a nice unambiguous syntax for it yet.

Slava

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171103/f4f585e1/attachment.html>


More information about the swift-evolution mailing list