[swift-evolution] [Proposal] Partial initializers

[Matthew Johnson]

> On Jan 20, 2016, at 8:48 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> Hm. Some comments:

Thanks for providing lots of feedback!

> 
>> This proposal does not introduce extensions with stored properties, however partial initialization is closely related to that topic. Class extensions with stored properties would be required to have an extension initializer. That extension initializer would effectively be treated as a partial initializer by designated initializers of the class. 
> 
> I feel like most "extensions with stored properties" proposals have to cover extensions from another module, but maybe those properties are required to be lazy or something.
> 
> 
>> 3. Partial initializers and initialization methods may include an access control modifier specifying their visibility.
> 
> 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.

I have no problem with banning `public`partial inits and only exposing the ordinary method aspect of `public` initializer methods.  Unless this is controversial on the core team I will make this change.

> 
> 
>> 9. The compiler keeps track of the properties initialized by a partial initializer or initialization method and uses that knowledge when enforcing initialization rules in phase one in the calling initializer.
> 
> If a struct partial initializer is defined in another file, this would require reading the body of the initializer to determine what variables it initializes. We currently don't type-check any bodies outside of the primary source file when doing a normal, multi-process compilation.

Are you recommending a same-file requirement?  I wouldn’t have a problem with that.  I’m trying to keep this proposal as focused as possible and will make any changes necessary to address implementation considerations.

> 
> You're missing a DI condition here in the sub-bullets, which is that the partial initializer must initialize its subset of stored properties on all paths.

Agree.  I left that implicit but will call it out explicitly.

> 
>> 9 iv. A partial initializer or initialization method can only write to a property once, including var properties.
> 
> I'm not sure why John thinks this would make things easier but I'll believe him. Seems like it'd be the same as doing it in phase 1 of an initializer.

I may have misinterpreted John’s comment.  I’m guessing it had to do with releasing the old value if it was set prior to calling the partial init like you mentioned in the other thread.  Hopefully he can clarify.

> 
> ---
> 
> Can an initializer method be overridden? If so, I assume that does not override the "initializer" part, just the "method" part? If not, can we require the 'final' to be explicit?

Good question.  I was thinking of them as implicitly `final` but didn’t call that out.  If you think they should be explicitly marked `final` I will make that change.

> 
> Can the method be marked @objc? 'dynamic'? I would assume "yes", because it's not really different from any other method, but I think it ought to be called out.

I suppose so if that doesn’t create any implementation challenges around the initializer aspect.

> 
> I don't personally like the call syntax but I don't immediately have anything better to offer. I do think that part of this proposal should include naming guidelines for these things.

I don’t love it but don’t have a better idea either.  It’s a good candidate for bike shedding and we might be able to find something better.

What do you have in mind in terms of naming guidelines?  I can imagine UI classes having partial inits like “appearanceProperties” and “animationProperties”, etc.  Those names wouldn’t be good for an initializer method though.

> What happens when you call an init method from phase 2 of initialization? Is that just illegal?

Good question.  I should have addressed this.  Partial initializers should not be callable during phase 2.

It probably make senses to allow initializer methods to be called during phase 2 using the usual method syntax just like any other method.  What do others think?

> 
> 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. I'm thinking about someone coming across the construct for the first time: would they understand what it was doing? Would they understand the error messages they would get?

What I like about this approach is that it is a general tool for factoring initialization code using techniques similar to those we use in other code.  Lots of people do similar things in Objective-C, but in an obviously unsafe way.  This would help ease their migration to Swift while helping them do this safely.

I think the best way to think about the added complexity is to consider the *incremental* complexity and benefit over Swift’s initialization model.  I think it is a pretty modest change to understand for those who already understand the existing rules while providing substantial benefit in some cases.

> 
> (Specifically on that note: "init func" is probably okay because it's a special kind of func, but I think I would personally prefer to keep the 'partial' keyword for partial inits, even though it's technically unnecessary.)

I would be happy with whatever syntax the core team thinks is best.  I like keeping it more concise but don’t mind `partial` if others like that better.

It’s just hard to tell what that is with several people involved.  Any recommendations on how to handle this when writing a proposal? 

> 
> Sorry for the somewhat scattered thoughts. Hope it's helpful.

Absolutely.  I really appreciate your feedback!

-Matthew

> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160121/d1c0fad6/attachment.html>