[swift-evolution] [Proposal] Factory Initializers

[Joe Groff]

> On Dec 18, 2015, at 12:39 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 18, 2015, at 8:15 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>> 
>> Now I'm confused: I thought the idea should enable class clusters, i.e. allowing AbstractBaseClass(42) to return something with the *dynamic* type of ConcreteImplementation but still the static type of AbstractBaseClass.
>> Otherwise I would just call ConcreteImplementation(42) if I wanted something of that static type.
> 
> Got it.  If that is the case, then yes, something like a “factory init” makes sense to me.  It is unfortunate that such a thing would make the swift initializer model even MORE complex :-) but it is probably still the right way to go.

In the implementation model, if not the language model, convenience inits today pretty much already are factory initializers, since the ABI allows for a different `self` object to be returned as long as it's a subclass of the current type, much like a factory method. Instead of adding another wrinkle to the initializer model, we could embrace this, and allow convenience inits to reassign `self` as in ObjC.  This would also bring more consistency between struct and class initializers, since struct initializers are already able to reassign `self` as well. We have to interop with the [[T alloc] init] model for ObjC classes, so we'd have to deallocate a wasted empty object if a convenience initializer for an @objc class changes self, but the ABI for pure Swift convenience initializers could be made to be callee-allocating to avoid that performance problem.

-Joe