[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Matthew Johnson matthew at anandabits.com
Thu Jan 7 09:24:29 CST 2016 

> On Jan 7, 2016, at 9:02 AM, plx via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I like the general notion of something along these lines but admittedly haven’t had time to dig into the proposal specifics yet.
> 
> I have some concerns about cross-interactions with other features that are either also under discussion or are at least very anticipatable.
> 
> First, I know there has already been some discussion of allowing definition of stored fields in (some) extensions (e.g., something like allowing definition of stored fields in extensions within the module that defines the type).
> 
> E.G., something like this may become possible (assume all files are compiled together):
> 
>    // in `ComplicatedClass.swift`
>    class ComplicatedClass {
>      let text: String
> 
>      // how will this get expanded,
>      // given the extensions below?
>      memberwise init(...)
>    }
> 
>    // in `ComplicatedClass+Foo.swift`
>    extension ComplicatedClass {
>      var fooData: Foo? = nil
>      // presumably stuff-involving-`fooData`
>    }
> 
>    // in `ComplicatedClass+Bar.swift`
>    extension ComplicatedClass {
>      var barData: Bar = Bar.standardBar
>      // presumably stuff-involving-`barData`
>    }
> 
> It doesn't seem impossible to specify how the memberwise-initialization would interact with constructs like the above, but I'd worry a bit about it making a feature that's already looking *rather* complicated even more so.
> 
> Especially since, if I had to pick just one, I'd think the ability to define stored properties outside the initial definition is a bigger win than a nice memberwise-initialization construct, even though both seem handy.

I followed the stored-properties-in-extensions discussion reasonably closely.  My understanding is that the extension will need to initialize its own properties, either with an initial value or with a `partial init`.  Designated initializers would be required to call the `partial init` for any extension that defines one.

This being the case, memberwise initialization would not directly interact with this feature at all.  Memberwise initializers declared in the main body of type itself would only expose stored properties defined in the type itself.  

It would also be possible to support `partial memberwise init` in extensions which would expose the stored properties declared in the extension as part of a partial initializer.

I don’t think there are difficult complications here.

> 
> Secondly, I’m a bit unsure how this will interact with e.g. the property-behavior proposal if both wind up ratified. For `lazy`, the interaction with `memberwise` is easy — it is omitted from the list — but when you get into e.g. something like a hypothetical `logged` or `synchronized` or `atomic` — wherein there is custom behavior, but the field would still need initialization — you’d want them to be included in the
> `memberwise` init.

My thought here is that a behavior would define whether a property allows and / or requires initialization in phase 1 or not.  This is probably necessary independent of memberwise initialization.  Properties that allow or require phase 1 initialization would be eligible for memberwise initialization.  Properties that don’t allow phase 1 initialization would not be eligible for memberwise initialization.

> 
> It’s a bit unfair to bring up another proposal, but this proposal and something like the property-behavior proposal *would* need to work well together (if both are approved).

Agreed.  That is why there is a rule that references property behaviors in the proposal.

> 
> Thirdly, I’m not sure what the current plans are (if any) for users to be able to specify the precise memory-layout of a struct; apologies if this is already a feature, I simply haven’t looked into it.
> 
> **Today**: I order stored-field declarations for ease-of-reading (e.g. grouped into logical groups, and organized for ease-of-reading).
> 
> **Under Proposal**: I sometimes will get to choose between the “ease-of-reading” declaration ordering and the “cleanest-reading memberwise init” declaration ordering. These may not always be identical.

Agree.  This is something that could be addressed in a future enhancement if necessary.  This proposal is focused on the basic mechanism.

Also, nothing in the proposal prevents you from continuing to write a manual initializer when the synthesized initializer will not do what you require.  If you are already explicitly restating the property identifiers to specify parameter order you are already half way to a manual initializer implementation.  

Granted, if you need more than one memberwise initializer you would have to duplicate that effort.  But re-ordering is going to have a hard time providing enough value if the basic feature does what we need in the majority of cases.


> 
> **Future?**: I may have to choose between the “ease-of-reading” declaration ordering, the “cleanest-reading member wise init” declaration ordering, and (perhaps?) the “intended memory-layout” declaration ordering.
> 
> I don’t want to make this proposal more-complicated than it already is, but I worry a bit about having too many things impacting the choice of how to order declarations in source files; it may be better to include a way to explicitly declare the ordering-for-memberwise:
> 
> E.G., some way of explicitly indicating the memberwise ordering, perhaps like this:
> 
>    // syntax example re-using `ComplicatedClass`
>    class ComplicatedClass  {
>      @memberwise($parameterList)
>      // ^ can use just @memberwise to get default ordering + the defaults from
>      //   the property declarations, but perhaps require the explicit listing
>      //   whenver the ordering is not well-defined (e.g. if you have properties
>      //   declared in extensions…then you need to order it yourself)
>      // 
>      //   @memberwise(text="Example",barData=,fooData)
>      //   - `text="Example"` => memberwise init has text="Example"
>      //   - `barData=` => memberwise init has `barData` w/out default
>      //   - `fooData` => memberwise init has `fooData` w/default if it has one
>      //
>      //   …and e.g. the above would make:
>      //
>      //   memberwise init(...)
>      //
>      //   ...expand-to:
>      // 
>      //   init(text:String = "Example", barData: Bar, fooData:Foo?=nil)
>      //
>      //   ...and with the @memberwise declaration supporting a `...` for `super`
>      //   placement, like so:
>      //
>      //   // superclass members come before:
>      //   @memberwise(...,)
>      //   @memberwise(...,$parameterList)
>      //
>      //   // superclass members come after      
>      //   @memberwise(,...)
>      //   @memberwise($parameterList,...)
>      //
>      //   ...perhaps with tweaked syntax (`@memberwise(...,$)` or `@memberwise(...,self)`)
>      //   to be bit easier to read when you don't have an explicit parameter list?
>    }
> 
> ...which of course potentially only-further complicates the feature in some ways, but avoids having this use of this feature *necessarily* impact how one might choose to order declarations?
> 
>> On Jan 6, 2016, at 4:47 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "Flexible Memberwise Initialization" begins now and runs through January 10th. The proposal is available here:
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>> 
>> 	https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>> 	* What is your evaluation of the proposal?
>> 	* Is the problem being addressed significant enough to warrant a change to Swift?
>> 	* Does this proposal fit well with the feel and direction of Swift?
>> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris
>> Review Manager
>> _______________________________________________
>> 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

More information about the swift-evolution mailing list