<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Before diving into the details, I’d like to reiterate the point of my review:</div><div class=""><br class=""></div><div class="">I don’t know exactly what the better mechanism is, but I strongly suspect that it’s out there. My wish is to defer the current very narrow proposal in favor of a more searching for a general mechanism.</div><div class=""><br class=""></div><div class="">I don't think we should permanently reject a thoughtful proposal only because a better proposal <i class="">might</i> be out there. Neither do I think that having to come up with a better mechanism within the review period should be a requirement of not immediately accepting the proposal.</div><div class=""><br class=""></div><div class="">That’s the upshot of my review. The rest of this message is just noodling….</div><div class=""><br class=""><blockquote type="cite" class="">Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>&gt; wrote:</blockquote></div><blockquote type="cite" class=""><div class=""><br class=""></div><div class="">I don't think the `members` tuple is a good alternative here. It looks good on paper, but think about what it actually would&nbsp;need to involve to match this proposal and its likely enhancements:<br class=""><br class="">- It would need to have different elements at different levels of accessibility, and we would somehow have to select the&nbsp;right level for the matching initializer.<br class="">- It would need to include only properties *writable* at that level.<br class="">- It would need to include only stored properties.<br class="">- It would need to include only properties that are either `var`s or uninitialized `let`s.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">You’re imagining with all these that the initialization code must be _completely_ synthesized. But as I said, I’d happily shoulder the burden of just a little more explicitness if I got a mechanism that wasn’t so inflexible as the proposal at hand.</div><div class=""><br class=""></div><div class="">I’m quite sure that the automated synthesizing won’t always get it right. It tries, but I’ll want inevitably want manual control. And thus…</div><br class=""><blockquote type="cite" class=""><div class="">- But we would need mechanisms to add items that have been excluded, and remove items that have been included.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">…I’d want such mechanisms with the current proposal too — but there’s no obvious future expansion direction for them.</div><br class=""><div class=""><blockquote type="cite" class="">Plus there's all the weirdness around using it to reassign constants.<br class=""></blockquote><br class=""></div><div class="">It would follow the same rules as normal assignment. No weirdness there.</div><br class=""><blockquote type="cite" class="">On Jan 10, 2016, at 3:37 AM, Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="">On Jan 10, 2016, at 1:17 AM, Thorsten Seitz &lt;<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>&gt; wrote:<br class="">Yeah. Still brainstorming here :-)<br class=""></blockquote><br class="">So you know, I didn't really mean to put you specifically on the spot here; you're obviously trying to find concrete&nbsp;solutions to these problems. But it seems to me that what we're going to end up with is that, instead of having this:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>public init(members...: Members) {<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><span class="Apple-tab-span" style="white-space:pre">        </span>self.members = members<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}<br class=""><br class="">We'll have something more like:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>public init(members...: Members.Public.Initializable) {<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><span class="Apple-tab-span" style="white-space:pre">        </span>self.members.public.initializable = members<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</blockquote><br class=""><div class="">Well, in my brainstorms, I was loosely imagining that when members is used as an lvalue, it would infer the subset being assigned to using the labels of the rhs tuple. So you could do this:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>public init(members...: Members.Public.Initializable) {<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><span class="Apple-tab-span" style="white-space:pre">        </span>self.members = members<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}<br class=""></div><br class=""></div><div class="">…or maybe something more arbitrarily composable:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>public init(members...: Members.only(public, var, except: meaningOfLife)) {<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><span class="Apple-tab-span" style="white-space:pre">        </span>self.members = members</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; meaningOfLife = 42</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}<br class=""></div><div class=""><br class=""></div><div class="">…or even:</div><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>public init(members...: Members.only(public, var).except(meaningOfLife)) {<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><span class="Apple-tab-span" style="white-space:pre">        </span>self.members = members<br class="">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; meaningOfLife = 42<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}<br class=""><div class=""><br class=""></div><div class="">Breaking that down:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>Members.only(public, var) → (a: Int, b: String, meaningOfLife: Int)</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; .except(meaningOfLife) = generic operation that works on any tuple →&nbsp;(a: Int, b: String)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>members arg then gets a value like (a: 4, b: “foo”)</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>self.members =&nbsp;(a: 4, b: “foo”) infers that a and b are being assigned to, and expands to:</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>a = 4</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>b = 4</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>…with no additional language features necessary for access control, let/var, etc.</div><div class=""><br class=""></div><div class=""><div class="">Something like that. Who knows? It’s obviously a complicated discussion. The point is just that it would do a lot more for the language to have orthogonal features for:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">turning tuples into variadic parameters,</li><li class="">turning member or member types into a tuple, the former of which can be an lvalue, and</li><li class="">subsetting and reordering tuples.</li></ul><div class=""><br class=""></div></div><div class="">…with&nbsp;<i class="">none</i>&nbsp;of those being limited to initializers.</div></div><div class=""><br class=""></div><div class="">Some mechanism like this would generalize much better than the current proposal, which breaks down quickly if you step outside its imagined use cases.</div><div class=""><br class=""></div><div class="">I don’t see the current proposal leading in this more useful direction, though it sounds like Matthew has something up his sleeve.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div></body></html>