[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization
tseitz42 at icloud.com
Sun Jan 10 03:17:32 CST 2016
> 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 :-)
More information about the swift-evolution