[swift-evolution] [Proposal] Use inout at function call sites
clattner at apple.com
Fri Jan 29 22:38:37 CST 2016
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.
> 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.
> 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.
More information about the swift-evolution