<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Would maybe stick with @abstract or @deferred instead of the verbose @requires_override as the keyword.<div class="">Those keywords are known from other languages.</div><div class=""><br class=""></div><div class="">+1 with the rest, though.</div><div class=""><br class=""></div><div class="">It's really a pain to not have access to abstract classes.</div><div class="">My workaround for similar cases is</div><div class="">- Put function definitions with deferred implementation into protocols.</div><div class="">- Mark initializer of base class as private to prevent instantiation of the incomplete class.</div><div class="">- Put subclasses into same file as base class.</div><div class="">- In subclass, inherit from both the base class and the protocol, and override initializer as public.<br class=""><div class=""><br class=""></div><div class="">Also agree with the irrelevance for UITableViewController. The class works perfectly fine without the overrides.</div><div class=""><br class=""></div><div class="">Etan</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 14 Dec 2015, at 00:27, Kevin Ballard 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=""><title class=""></title>
<div class=""><div class="">Seems to me this doesn't actually make sense on protocols at all. The scenario of a base superclass like UITableViewController that conforms to a protocol but only makes sense if its children override methods doesn't actually have anything to do with the protocol at all, as it's certainly not true any class that conforms to UITableViewDelegate/DataSource wants subclasses to override methods, that's only true of UITableViewController.<br class=""></div>
<div class=""> </div>
<div class="">Given that, the proposed @abstract is actually something that would make sense to put on the implementation of a method in a class, not on a protocol. There's simply no such thing as an abstract protocol. And when put on a method, it would probably be better to just call it @requires_override, because that's all it means.<br class=""></div>
<div class=""> </div>
<div class="">All that said, it doesn't actually make sense to put the attribute on UITableViewController's methods either. And the reason for that is that if you use a storyboard with static cells, you can have a UITableViewController that functions perfectly fine without overriding any of the UITableViewDelegate/DataSource methods. So requiring that a subclass implement any of those methods would actually be wrong.<br class=""></div>
<div class=""> </div>
<div class="">So overall, there are use-cases for a @requires_override attribute, but UITableViewController actually isn't one of them (in fact, I don't think anything in UIKit/Foundation qualifies).<br class=""></div>
<div class=""> </div>
<div class="">Regarding `required`, that's not appropriate because `required` means that every single descendant class must provide an implementation. And it's only allowed on init methods because the whole point of `required` is to remove the special-cased behavior of init for subclassing (e.g. that it's not inherited by subclasses). There's no other place besides init() where it makes sense to require every single descendant class to provide an implementation because every other method will get inherited (and even if your base class's implementation should always be overridden, if your child overrides it, your grandchild certainly doesn't have to!).<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard</div>
<div class=""> </div>
<div class="">On Sun, Dec 13, 2015, at 02:16 PM, Jacob Bandes-Storch via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><div dir="ltr" class=""><div class="">How about reusing the keyword "required" for this? It's already used (and has a similar meaning) for initializers.<br class=""></div>
<div class=""> </div>
<div class="">I think NSSecureCoding is a good example of a use case.<br class=""></div>
<div class=""><div class=""> </div>
<div class=""><div class="">On Sat, Dec 12, 2015 at 9:14 AM, Arthur Ariel Sabintsev via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;" class=""><div dir="ltr" class=""><div class="">TL;DR: Force explicit protocol conformance of non-optional methods for child classes on an opt-in basis.<br class=""></div>
<div class=""> </div>
<div class="">Currently, a child class that inherits their parent class' protocol conformations are not explicitly required to override their parent classes implementation of a protocol. For example, a custom class, MyTableViewController, does not explicitly have to override the non-optional methods of the protocols (i.e., UITableViewDataSource, UITableViewDelegate) to which UITableViewController conforms. <br class=""></div>
<div class=""> </div>
<div class="">For many protocols, the superclass implementation of a protocol method may be enough. Therefore, this feature should off by default, and only enabled if the creator of the protocol requires it (for whatever reason). I suggest using a new `@abstract` attribute to designate if a protocol requires explicit conformance for children of a conforming parent class. This choice of naming for the attribute is along the lines of what other languages call an Abstract Class, which is what I'm trying to have added to Swift in this fairly long-winded post.<br class=""></div>
<div class=""> </div>
<div class="">@abstract protocol P: class {<br class=""></div>
<div class=""> // All methods defined in here would need to be explicitly overridden by the conforming class's children.<br class=""></div>
<div class="">}<br class=""></div>
<div class=""> </div>
<div class="">If you want to have optional methods in your protocol, then using the @abstract attribute gets kind of messy, as you also have the @objc attribute.<br class=""></div>
<div class=""><div class=""> </div>
</div>
<div class=""><div class="">@abstract @objc protocol P: class {<br class=""></div>
<div class=""> // All non-optional methods defined in here would need to be explicitly overridden by the conforming class's children.<br class=""></div>
<div class="">}<br class=""></div>
</div>
<div class=""> </div>
<div class="">Thoughts?<br class=""></div>
<div class=""> </div>
<div class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div style="font-family: helvetica, arial;" class=""><span class="colour" style="color:rgb(34, 34, 34)"><span class="font" style="font-family:arial, sans-serif">Best,</span></span><br class=""></div>
<div style="font-family: helvetica, arial;" class=""> </div>
<div style="font-family: helvetica, arial;" class=""><span class="colour" style="color:rgb(34, 34, 34)"><span class="font" style="font-family:arial, sans-serif">Arthur / <a href="http://sabintsev.com/" class="">Sabintsev.com</a></span></span><br class=""></div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class=""><img style="min-height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/5107855c90121e85e876e3bca775a895d280b9ee915b5c0c15464bbdff448427/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d305d2232437952624a584252457c44424a416c4434494b444e466b6b6a60725f4f67745972514f4266513131797669345276527e49516c4834325279653379317d41313957513d46626131454933617a6f655734396a457c4757347075744d22364247633e694531537647335769656d2236443a46695e4356426a5165455467455464495645566f65447e68787464733735687c6267413a614441667d4853446f426d6e49327d437f4e415169324d2232465248535e4a535363365843555752467d2236424b6657766b4470596248697c6744724173776536787f4a48317b68387363455531575f4478796d223648657c686f62454d2232443d23344/open" class=""> <br class=""></div>
<div class="">_______________________________________________<br class=""></div>
<div class="">
swift-evolution mailing list<br class=""></div>
<div class=""> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
<div class=""> </div>
</blockquote></div>
</div>
</div>
<div class=""><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/649edb3c32a2262c2151f8f0ec4ddac7bedf00713aeb360a5cc2f2f023fddc71/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3148765176786c673171614a7d2236454230345272776e41677a615154425354673d2232496e4334724667427940383a4f65584c4c64487b67727974534e4c655d69585b616849413d22324733797a526a41364742353b6a7664796a43375054523e43733750523f46566670745e42723933417f653a43727b66395d624f6945403136405d223643664851793e667e614e41455243544166646a644573403c6c4a71303f4867787436317138724d44313d223648677054657d2236455d4e463977516a617d613d4d22364c61566965554371485f6b63617835547a63544c67636a7e6a576d23344d23344/open" class=""><br class=""></div>
<div class=""><u class="">_______________________________________________</u><br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</blockquote><div class=""> </div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=tTTJ5sn5y0uc3ODSZa-2BndLNwXCDS7T2cq5OlDDhG0RvNtFFWhH5kDG49Z7rE63kkWfNXj14C3cbRchCugB1n6a1ZHBZlc8kO4BVws29LDjMfrjYZQ5RFMpeq7FxqbxpXLJfEKTRPXFFyw3eJiiZ5FQM0Sxi6UM0XyXNdra26whv6C63t4IJV44eiPdVlxD9hkwiwm23yvdNMZtDJDrTkEpvl6zGpF7oMJPJHrKsJJfs-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>