<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="">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><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></body></html>