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
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
