<div dir="ltr">Having trouble locating it, any help, anyone?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 4:58 PM, Andrey Tarantsov <span dir="ltr"><<a href="mailto:andrey@tarantsov.com" target="_blank">andrey@tarantsov.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hey, and welcome!<div><br></div><div>We actually talked about it some time before Christmas, with possible names like @must_override. The talks seemed to be going well, but I haven't been following the discussion closely, so cannot provide a summary or status, unfortunately. Please try to find it in the archives.</div><div><br></div><div>A.</div><div><br></div><div><br><div><blockquote type="cite"><div>On Jan 15, 2016, at 6:38 AM, Nate Birkholz via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div>My first ever post on this list or any open source project, sorry if I'm not following procedure accurately, here.</div><div><br></div><div>Currently, the "required" keyword on an initializer causes subclasses to implement their own init methods in place of the so-marked initializer. I propose extending the use of the required keyword to methods such that when a new subclass is created, it must create its own unique implementation of the method, or at ;east explicitly invoke the superclass implementation via super.methodName()</div><div><br></div><div>Requiring child classes to implement the method will improve the maintainability of codebases over time and is a logical extension of the current implementation on initialization. This will provide a useful, nondisruptive, nonbreaking communication tool.</div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div>Nate Birkholz</div>
</font></span></div><span class="HOEnZb"><font color="#888888">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=LRtxqIpN0uduUbaiFaLozLZv7i-2BSLNOBgkrlBNK2PSXQdC0eprn8rgToVGT4HlNxjGcbXSyOsxztB7XUq1a8H7ufqaCXxz-2FSJ9q8FAhkgEzd3Nnzj6YzfRu827UpksA902Of1usI3XYC02Vjfpa0NPwZsEObTtStMVLgJwt6w5QpKPJG3JDKKohr49m1eT6uKNju5v2k-2FmwnTqwd4WSFgq9-2BvWRCDaR85Alb8nyEmwk-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></font></span></div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Nate Birkholz</div>
</div>