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

[Thorsten Seitz]

> Am 09.01.2016 um 21:24 schrieb Brent Royal-Gordon <brent at architechies.com>:
> 
>> 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.

That’s a good point. Maybe some kind of type narrowing according to accessibility (probably explicit)?

> - It would need to include only properties *writable* at that level.

Or maybe have both readable and writeable parts/views, i.e. members.readable and members.writable

> - It would need to include only stored properties.

They would be included in a readable part/view, though.

> - It would need to include only properties that are either `var`s or uninitialized `let`s.

That’s why I separated into vars and lets in my playground. This is already quite workable with regards to assignability if still a bit clunky.

> - But we would need mechanisms to add items that have been excluded, and remove items that have been included.

Yes, that’s still a big question. This would again require some kind of type narrowing according to properties excluded.

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

That’s why I separated into varMembers and letMembers in my playground. No reassignment possible but assignment within initializers is fine.

> 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

The missing things seem to be mostly
(1) type narrowing according to accessibility (e.g. "let x: public Foo“ would give x the type of Foo narrowed to the public interface even if more of Foo would be visible here)
(2) maybe type narrowing according to readability/writability
(3) type narrowing according to excluded properties (e.g. let x: S#without(s0) would give x the type of S narrowed to the interface where s0 does not appear)
(4) ability to spread a struct into a parameter list (the struct’s property names becoming the parameter names)

I don’t immediately see a general use case for the (1)+(3) but could imagine that (4) would be generally useful and maybe even (2).
Maybe someone else has an idea on their usefulness or maybe there is a completely different solution with a different feature set.

> lot less clear. In the end, I don't think that'll actually be a win.

Yeah. Still brainstorming here :-)

-Thorsten