[swift-evolution] [Proposal] Factory Initializers

[Riley Testut]

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 <dabrahams at apple.com> wrote:
> 
> 
>> On Dec 18, 2015, at 3:20 PM, Riley Testut via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>>> 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
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -Dave
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/7ab83940/attachment.html>