I guess a better question here is, is it worth modifying the existing compiler/ABI behavior to explicitly allow returning instances from convenience initializers? Personally, while I prefer the use of return statements (especially because they're already used to return nil from failable initializers), I know that finalizing Swift 3 is a priority, and if we can have essentially the same functionality while also taking advantage of what already is implemented, that might make a more sense for implementation.
Of course, I'm making plenty of assumptions about the difficulty/time to implement both of these solutions. Would love to hear what the expected methodology would be to implement both of those, and if anyone has genuinely strong preferences either way. > On Dec 18, 2015, at 6:53 PM, Dave Abrahams <[email protected]> wrote: > > >> 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]> wrote: >>>> >>>> >>>>> 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 >> >> >> _______________________________________________ >> 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
