> On Dec 18, 2015, at 12:39 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > >> On Dec 18, 2015, at 8:15 AM, Thorsten Seitz <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
