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

[Trent Nadeau]

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


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/a97090c5/attachment.html>