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

[Thorsten Seitz]

I actually like the `convenience`-ness being explicit.

-Thorsten


> Am 01.03.2016 um 21:04 schrieb Joe Groff via swift-evolution <swift-evolution at swift.org>:
> 
> On Feb 29, 2016, at 10:53 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto: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.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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