[swift-evolution] [Proposal] Partial initializers

[Slava Pestov]

Adding more details…

> On Jan 20, 2016, at 8:46 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> I'm a little concerned about exposing these things publicly: there's no point if the struct or class has non-public fields (because new non-delegating initializers can't initialize the non-public fields), and by default every struct and class is allowed to add non-public fields in new versions of a library. (See the LibraryEvolution.rst doc for more info.) I can kind of see making these private vs. internal, but that has other issues (see below).
>> 
>> Even in the case where all fields are public and the struct promises not to change any fields, you'd also have to promise that the partial initializer never changes which properties it's initializing; that's now part of the binary interface of the file. That's unusual for something that behaves like a function; usually the body is not part of the ABI.
>> 
>> I'd much rather just ban 'public' and never have partial inits be part of a library's public interface. Public initializer methods would be presented as plain methods, with no hint of their initializer origins.

If we just go with @_transparent functions for partial initialization, there are no new rules to add regarding ABI resilience. :-)

>> I'm ultimately still not convinced that this is the right way to reduce initializer boilerplate (phase 1 duplication between initializers, or shared code between initializers and methods). It again adds complexity to the language, and that added complexity may not be worth the payoff.

This is really my main concern with the proposal.

Also I would suggest that the part regarding argument forwarding could probably be split off and discussed separately — I think this has applicability outside of initializers.

Slava

>> Jordan
>> 
>> 
>>> On Jan 14, 2016, at 20:08, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I have completed the second draft of my partial initializers proposal (the first really complete draft). 
>>> 
>>> This proposal also includes some discussion of memberwise initialization at John McCall’s request.  If anyone would like to continue discussing that topic informally I will be happy to do so, however any such discussion should happen on one of the existing memberwise initialization threads or on a new thread related to that topic.  Please do not let that section of the document be a distraction from the partial initializer proposal itself.
>>> 
>>> The new draft can be found here:
>>> 
>>> https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md <https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md>
>>> 
>>> I really appreciate any feedback you have!
>>> 
>>> -Matthew
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160120/fa43b016/attachment.html>