> On Nov 2, 2017, at 8:29 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution >> <[email protected] <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
