<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 8:29 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span></div></blockquote></div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Hypothetical replacement for UIControl.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol UIControl: UIView {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func sendAction(_ action: Selector, to target: Any?, for event: UIEvent)</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Maybe allow them to declare automatically-added storage, perhaps even private to the protocol:</div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>In general I’m not convinced this is a useful feature.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Probably something like `super` for when you want to override a default implementation but still call it:</div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>Slava</div><br class=""></body></html>