[swift-evolution] Pitch: make class initialization complexity more progressively disclosed

Joe Groff jgroff at apple.com
Tue Mar 1 14:04:00 CST 2016

On Feb 29, 2016, at 10:53 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160301/43fb03d0/attachment.html>

More information about the swift-evolution mailing list