[swift-evolution] [Proposal] Use inout at function call sites
tanadeau at gmail.com
Sat Jan 30 09:21:47 CST 2016
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.
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.
On Fri, Jan 29, 2016 at 11:38 PM, Chris Lattner <clattner at apple.com> wrote:
> 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.
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution