[swift-evolution] [Proposal Draft] Flexible memberwise initialization
Matthew Johnson
matthew at anandabits.com
Tue Dec 22 10:46:19 CST 2015
Hi Chris,
I have given your feedback a lot of thought and have taken another run at this proposal from a slightly different angle. I believe it is a significant improvement.
I believe the programmer model is now very clear straightforward:
The set of properties that receive memberwise initialization parameters is determined by considering only the initializer declaration and the declarations for all properties that are at least as visible as the initializer (including any behaviors attached to the properties). The rules are as follows:
• Their access level is at least as visible as the memberwise initializer.
• They do not have a behavior which prohibits memberwise initialization.
• The property is not annotated with the @nomemberwise attribute.
• The property is not included in the @nomemberwise attribute list attached of the initializer. If super is included in the @nomemberwise
The parameters are synthesized in the parameter list in the location of the ... placeholder. They are ordered as follows:
• All properties without default values precede properties with default values.
• Within each group, superclass properties precede subclass properties.
• Finally, follow declaration order
The new model has also dramatically simplified the implementation details. No more need for the compiler to scan the initializer body!
There are still some details present that you provided feedback on. My reply from last night is still valid discussion around those issues. Please reply inline to that message if possible.
I’m sure there are still plenty of details to discuss and work through, but I hope you will agree that these changes are a step in the right direction.
https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md>
Matthew
> On Dec 21, 2015, at 7:47 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Dec 21, 2015, at 11:32 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I have completed a draft of the proposal I have been working on for flexible memberwise initialization. I am really looking forward to your input and will be refining the proposal based on our discussion.
>>
>> I am including a current snapshot of the proposal in this message. I will keep the proposal up to date on Github at this link:
>>
>> https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md>
> This is a really really interesting approach, I really like it. Detailed comments below, I’m skipping all the stuff I agree with or have no additional comments on:
>
>>
>> Flexible Memberwise Initialization
>>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#replacing-the-current-memberwise-initializer>Replacing the current memberwise initializer
>>
>> struct S {
>> let s: String
>> let i: Int
>>
>> // user declares:
>> memberwise init() {}
> It never occurred to me to allow a body on a memberwise initializer, but you’re right, this is a great feature. I love how this makes memberwise init behavior a modifier on existing initializers.
>> Properties with initial values
>>
>> struct S {
>> let s: String = "hello"
>> let i: Int = 42
>>
>> // user declares:
>> memberwise init() {}
>> // compiler synthesizes:
>> init(s: String = "hello", i: Int = 42) {
>> self.s = s
>> self.i = i
>> }
>> }
> In the case of let properties, I’m uncomfortable with this behavior and it contradicts our current init rules (the synthesized code isn’t legal). Please change the example to var properties, and then it’s can fit with the model :-).
>
> That said, I think the interaction of explicit initializers and memberwise initializers begs discussion. It would be a much simpler model to only get memberwise parameters for properties without an explicit init. Have you considered this model, what are the tradeoffs with allowing vars to overwrite them? Allowing an explicit init to be overwritten by the memberwise initializer seems potentially really confusing, and since you allow explicit arguments on inits, this could always be handled manually if someone really really wanted it. For example, they could write:
>
> memberwise init(s : String) {
> self.s = s
> }
>
> If they wanted to get the sugar of memberwise inits (presumably for other properties without an explicit init) but still allow one to be overwritten.
>
>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#partial-memberwise-initialization>Partial memberwise initialization
>>
>> struct S {
>> let s: String
>> let i: Int
>>
>> // user declares:
>> memberwise init() {
>> i = getTheValueForI()
>> }
>> // compiler synthesizes (suppressing memberwise initialization for properties assigned in the initializer body):
>> init(s: String) {
>> self.s = s
>> // body of the user's initializer remains
>> i = getTheValueForI()
>> }
>> }
> This doesn’t seem like the right behavior to me. The compiler shouldn’t be in the business of scanning the body of the init to decide what members are explicitly initialized. I’d suggest that the model simply be that the contents of the {} on a memberwise init get injected right after the memberwise initializations that are done. This mirrors how properties with default values work.
>
>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#lazy-properties-and-incompatible-behaviors>lazy properties and incompatible behaviors
>>
>> struct S {
>> let s: String
>> lazy var i: Int = InitialValueForI()
>>
>> // user declares:
>> memberwise init() {
>> }
>> // compiler synthesizes:
>> init(s: String) {
>> self.s = s
>> // compiler does not synthesize initialization for i
>> // because it contains a behavior that is incompatible with
>> // memberwise initialization
>> }
>> }
> Yes, this is likely to be subsumed into JoeG’s "behaviors” proposal. In the meantime, I’d suggest no behavior change for lazy properties.
>
>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#nomemberwise-properties>@nomemberwise properties
>>
>> struct S {
>> let s: String
>> @nomemberwise let i: Int
>>
>> // user declares:
>> memberwise init(configuration: SomeTypeWithAnIntMember) {
>> i = configuration.intMember
>> }
>> // compiler synthesizes:
>> init(configuration: SomeTypeWithAnIntMember, s: String) {
>> self.s = s
>> i = configuration.intMember
>> }
>> }
> @nomemberwise is an interesting extension, but since it is a pure extension over the basic model, I’d suggest moving this into a “possible future extensions” section. The proposal doesn’t need this feature to stand on its own.
>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#delegating-and-convenience-initializers>delegating and convenience initializers
>>
>> struct S {
>> let s: String = "hello"
>> let i: Int = 42
>>
>> // user declares:
>> memberwise init() {}
>> // compiler synthesizes:
>> init(s: String = "hello", i: Int = 42) {
>> self.s = s
>> self.i = i
>> }
>>
>> // user declares:
>> memberwise init(describable: CustomStringConvertible) {
>> self.init(s: describable.description)
>> }
>> // compiler synthesizes (adding forwarded memberwise parameters):
>> init(describable: CustomStringConvertible, i: Int = 42) {
>> self.init(s: describable.description, i: i)
>> }
>> }
> This example is introducing two things: convenience inits, but also parameter arguments. For the sake of the proposal, I’d suggest splitting the parameter arguments out to its own discussion. It isn’t clear to me whether the memberwise initializers should come before explicit arguments or after, and it isn’t clear if we should require the developer to put something in the code to indicate that they exist. For example, I could imagine a syntax like this:
>
> memberwise init(…) {}
> memberwise init(describable: CustomStringConvertible, ...) {
>
> Where the … serves as a reminder that the init takes a bunch of synthesized arguments as well.
>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#subclass-initializers>subclass initializers
>>
>> class Base {
>> let baseProperty: String
>>
>> // user declares:
>> memberwise init() {}
>> // compiler synthesizes:
>> init(baseProperty: String) {
>> self.baseProperty = baseProperty
>> }
>> }
>>
>> class Derived: Base {
>> let derivedProperty: Int
>>
>> // user declares:
>> memberwise init() {}
>> // compiler synthesizes (adding forwarded memberwise parameters):
>> init(baseProperty: String, derivedProperty: Int) {
>> self.derivedProperry = derivedProperty
>> super.init(baseProperty: baseProperty)
>> }
>> }
> This also seems unclear to me. We’re generally very concerned about tightly coupling derived classes to their bases (in an API evolution scenario, the two classes may be in different modules owned by different clients). Further, the base class may have multiple inits, and it wouldn’t be clear which one to get the arguments from.
>
>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#detailed-design>Detailed design
>>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#syntax-changes>Syntax changes
>>
>> This proposal introduces two new syntactic elements: the memberwise initializer declaration modifier and the @nomemberwise property attribute.
>>
> As before, I’d suggest splitting @nomemberwise out to a “potential future extensions section”.
>
>> Algorithm
>>
>> The steps described in this section will be followed by the compiler when it performs memberwise initialization synthesis. These steps supercede the synthesis of initialization for properties with initial values that exists today.
>>
>> When the compiler performs memberwise initialization synthesis it will determine the set of properties that are eligible for synthesis that are not directly initialized in the body of the initializer. It will then synthesize parameters for them as well the initialization of them at the beginning of the initializer body.
>>
> I’d strongly suggest considering a model where properties that have an explicit initializer don’t get a memberwise init.
>
> Have you considered whether computed properties make sense to loop into your model?
>
> Typo "initialzier”.
>
>>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#objective-c-class-import>Objective-C Class Import
>>
>> Objective-C frameworks are extremely important to (most) Swift developers. In order to provide the call-site advantages of flexible memberwise initialization to Swift code using Cocoa frameworks this proposal recommends introducing a MEMBERWISE attribute that can be applied to Objective-C properties and initializers.
>>
> This is also an orthogonal extension on top of the base proposal. I’d suggest splitting it off to a “possible future extensions” section as well.
>
>>
>> <https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/NNNN-flexible-memberwise-initialization.md#impact-on-existing-code>Impact on existing code
>>
>> The changes described in this proposal are strictly additive and will have no impact on existing code.
>>
>> One possible breaking change which may be desirable to include alongside this proposed solution is to elimintate the existing memberwise initializer for structs and require developers to specifically opt-in to its synthesis by writing memberwise init() {}. A mechanical transformation is possible to generate this declaration automatically if the existing memberwise initializer is removed.
>>
> I think that that would be very interesting to discuss, but I lean towards keeping our existing model for synthesizing a memberwise init if there is no other init in a struct (and we should do it for classes as well). Requiring someone to write "memberwise init() {}” is just boilerplate, and producing it as “internal” avoids most of the problems from being something undesirable being generated. That said, I see the argument that being more explicit is good.
>
> Overall, I’m a huge fan of this proposal and the direction you’re going in.
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/9680470a/attachment.html>
More information about the swift-evolution
mailing list