> On Dec 22, 2015, at 11:26 AM, David Owens II <da...@owensd.io> wrote:
>
> How are you going to deal with public properties creating a breaking change
> in the memberwise init()?
>
> Example:
>
> v1.0 of the API ships:
>
> struct Person {
> let name: String
> }
>
> v1.1 of the API ships:
>
> struct Person {
> let name: String
> let age: Int
> }
>
> When you use the implicit memberwise init(), the above change is now a
> breaking change. There are ways around it, but all seem fragile to me - for
> example, requiring a default value for new properties on the declaration site.
Adding a new member to a struct is itself a breaking change. I don’t see how
memberwise initialization makes this worse.
You could even use memberwise initialization in v1.0 of your API and then
update your implementation to be manual in v2.0 if necessary. Nothing in the
proposal prohibits you from taking full manual control if resilient API
evolution requires that.
One option I considered and think is still worth considering is requiring an
@memberwise attribute on properties to explicitly opt-in to memberwise
initialization. This is discussed in the proposal under alternatives
considered. You can find the rationale for my decision there. I do think it
is valid to debate which is a better default.
>
> Similarly, the order of the members must remain the same now, changing them
> is a breaking change. This is ok for structs today because the generated
> init() is only available within a module so all of the places that use it are
> limited within your own codebase.
The concern about order does have some validity. If declaration order does not
provide sufficient control the proposal could include something which allows a
different order to be explicitly specified for memberwise initialization.
Also, keep in mind that nothing in this proposal is *required*. You can always
decline to use the feature.
>
> This is why I do not like like the implicit behavior and the @nomemberwise
> attribute on the declaration of the property; it tightly couples together
> things that are inherently fragile.
Do you have any suggestions on how to improve the proposal without giving up on
its underlying goal of solving the M x N complexity problem (M members x N
initializers)?
If you haven’t taken a look at the updated proposal please do so. I’m sure
there will still be things you are not totally comfortable with but you might
like it better than yesterday's draft.
>
> -David
>
>> On Dec 22, 2015, at 8:46 AM, Matthew Johnson via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> 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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
