[swift-evolution] [Proposal Draft] Flexible memberwise initialization

[David Owens II]

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.

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.

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.

-David

> On Dec 22, 2015, at 8:46 AM, Matthew Johnson via swift-evolution <swift-evolution at 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

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