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

[Andrew Trick]

> On Jan 29, 2016, at 3:39 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 29, 2016, at 2:49 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> On Fri, Jan 29, 2016 at 2:44 PM, Trent Nadeau via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>> The `&` prefix operator is a holdover from C where it is usually read as
>>> "address of" and creates a pointer. While very useful in C due to its
>>> pervasive use of pointers, its meaning is not the same
>> 
>> Since there is an implicit conversion from &x expression to
>> UnsafePointer (for C interop), I have seen so many times people write
>> buggy code with the & operator, assuming that it is returning a stable
>> inner pointer to the data structure, like in C.  I don't have a
>> preference for the replacement, but I strongly believe that & is the
>> wrong way to spell this operation, because of the strong (and wrong!)
>> connection with C syntax that people tend to make.  'inout' keyword at
>> the call site sounds like a fine replacement to me.
> 
> Yeah, I like getting away from the baggage of the '&x' notation too. Implicit C pointer interop assumes that the C function has Swift-like by-value (for const) or inout-like (for non-const) semantics, and I like the idea of making that more explicit in the call site.

There's no arguing with the logic that & is inappropriate, and no arguing with Chris’ point that this is a bad place for a keyword or attribute.

Since no one has mentioned the obvious on this thread (although it must have been considered) I’ll just say it...

copy out or inout:
swap(x=, y=)

copy in:
sync(=x, =y)

Alternatively: &= as a kind of move operator.

I would even be ok eliminating inout in favor of move semantics, but I don’t think that will fly and doesn’t handle interop.

Andy