<div dir="ltr">Chris, thanks for your feedback. If Apple tried this idea internally and it didn't work out, then that's probably reason enough to abandon my proposal.<div><br></div><div>Do you think this (along with `in` and `out` params) should be added to the rejected list? If so, I can add it based on your and others' comments.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 11:38 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Jan 29, 2016, at 4:35 PM, Allen Ding via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> My 2 cents.<br>
><br>
> 1. At the use site (and in actual usage in my code), func(&value) is a visually recognizable enough pattern that it is "obvious" when I read it.<br>
<br>
</span>I agree.<br>
<span class=""><br>
> 2. At the call use, func(inout value) would also be obvious, but feels clunkier and may even be less immediately recognizable. Just my opinion. I find symbols easier to pick out when reading.<br>
<br>
</span>I agree, we actually evaluated this sometime between Swift 1 and Swift 2 and converted actual code using & to using inout on the call site, it looked worse. Clarity suffered, particularly when a parameter had an argument label.<br>
<br>
Keep in mind that we’re forcing this syntax on the caller side of things *only* to make it clear that something indirect is happening. There is no implementation reason to need this, it is to increase clarity. I am very concerned that making that “high pain” of such a sentinel would make defeat the purpose of this design decision in the first place.<br>
<span class=""><br>
> 3. I really need to be convinced that symmetry of usage at call site (for any language feature) and declaration is a desirable thing. In my opinion, declaration and use are orthogonal things and a lot of Swift already exhibits this asymmetry. e.g. parameter labels vs argument names, why doesn't calling a mutating func require mutating somewhere in the call to make it obvious the call might mutate the receiver.<br>
<br>
</span>Agreed.<br>
<span class=""><br>
> 4. The possibility of Swift becoming more Rust-like and letting this possibility drive this discussion does not seem like it should factor into the discussion of whether this proposal is a win.<br>
<br>
</span>Agreed. As a concrete example of this, people frequently ask for “in” and “out” parameters. With the current design, the call site would both use & for inout, in, and out. If we went with this proposal, we’d have to use in and out on the call side as well, which forces taking “out” as a keyword.<br>
<br>
Another problem with this is that this would break imported UnsafePointer’s, because it wouldn’t make sense to pass a “const char*” as “inout”. We’d be forced to design “in” parameters as a prerequisite for this feature.<br>
<br>
Another problem with this proposal is that it gets *unbearably* ugly if we end up with inout (and its future friends) being turned into attributes. Do you really want to see:<br>
<br>
swap(@inout x, @inout y)<br>
<br>
? Is that making code better somehow?<br>
<br>
Overall, I am very -1 on this proposal, for many of the reasons that Allen cites. This is a “seemingly obvious” proposal (which has come up many times before) which is pretty bad in practice.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Trent Nadeau</div>
</div>