> On Dec 18, 2015, at 3:20 PM, Riley Testut via swift-evolution > <[email protected]> wrote: > > I’m not opposed to assigning to self directly in convenience initializers > (especially if there is already support for it in the ABI). My only concern > would be that it feels less “natural” to do so than to simply return a value > from the initializer.
My instinct agrees with that. Also, reassigning self raises the question of whether an object is allocated (and partly initialized?) before the reassignment. Even if we can answer those questions in some clear way, I’d rather not have them come up at all. > That being said, I think that’s a very negligible disadvantage (if even > that), and if assigning to self is the easiest way to pull this off, I’m all > for it. > > However, should we keep convenience initializers as the only way to assign > self directly, and required initializers keep the same behavior as they do > today? And then would it make sense to disable the assignment to self in > struct required initializers to keep things consistent? Don’t have a strong > preference for any of these, but I do think they’re worth discussing. > >> On Dec 18, 2015, at 3:06 PM, Joe Groff via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On Dec 18, 2015, at 12:39 PM, Chris Lattner via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Dec 18, 2015, at 8:15 AM, Thorsten Seitz <[email protected] >>>> <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
