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

Brent Royal-Gordon brent at architechies.com
Sat Jan 9 14:24:40 CST 2016

> The members property should probably not be a tuple but a struct, thereby providing names for the values.
> I think splitting this property into two (varMembers and letMembers) with a read-only property members tying both together for convenience (members.vars, members.lets).

I don't think the `members` tuple is a good alternative here. It looks good on paper, but think about what it actually would need to involve to match this proposal and its likely enhancements:

- It would need to have different elements at different levels of accessibility, and we would somehow have to select the right level for the matching initializer.
- It would need to include only properties *writable* at that level.
- It would need to include only stored properties.
- It would need to include only properties that are either `var`s or uninitialized `let`s.
- But we would need mechanisms to add items that have been excluded, and remove items that have been included.

Plus there's all the weirdness around using it to reassign constants.

Basically, once you've applied all of the specialized rules needed to make the `members` tuple work for memberwise initializers, is `members` still going to be useful for anything else? Frankly, I think the answer to that question is "No". So we end up designing something that's maybe 1/4 orthogonal instead of 0/4 orthogonal, but is also a lot less clear. In the end, I don't think that'll actually be a win.

Brent Royal-Gordon

More information about the swift-evolution mailing list