<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I actually like the `convenience`-ness being explicit.<div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 01.03.2016 um 21:04 schrieb Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</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; -webkit-line-break: after-white-space;" class="">On Feb 29, 2016, at 10:53 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The simplifying observation here is that many classes (particularly in gui apps) are leaf classes that are not further derived from. Wouldn’t it be great if you could freely define a new class and not have to know about required and convenience initializers? It seems that we should only have to enforce these requirements if you a) further derive from this class within your module, or b) mark the class publicly-derivable-from.</span></div></blockquote></div><br class=""><div class="">I think we could avoid an explicit need for initializer decorations in most private or internal (a) cases too, since we have visibility into the entire class hierarchy. We could raise errors when specific subclasses don't provide `required` initializers, and infer the `convenience`-ness of each initializer from whether it `self.init` or `super.init` delegates. For non-publicly-subclassable classes there are no API liabilities to be concerned about.</div><div class=""><br class=""></div><div class="">-Joe</div></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></body></html>