[swift-evolution] [Proposal] Use inout at function call sites

[Chris Lattner]

On Jan 29, 2016, at 4:35 PM, Allen Ding via swift-evolution <swift-evolution at swift.org> wrote:
> My 2 cents.
> 
> 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.

I agree.

> 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.

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.

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.

> 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.

Agreed.

> 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.

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.

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.

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:

swap(@inout x, @inout y)

?  Is that making code better somehow?

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.

-Chris