[swift-evolution] [Pitch] Replace 'inout' with '&'

[John McCall]

> On Dec 21, 2015, at 11:19 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> On Dec 21, 2015, at 10:27 , Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>> 
>>> On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> On Sat, Dec 19, 2015 at 7:06 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> -1 to using '&' in the declaration; it's a sigil that doesn't mean anything as is. (I was originally on the side of using 'inout' at the call site as well, i.e. "swap(inout x, inout y)", but it was considered too verbose.)
>>> 
>>> I'd actually suggest that we reconsider this.  '&' at the callsite has deep associations with C semantics, and I have too frequently seen buggy code using '&x' combined with one of the C interop implicit conversions to "get a pointer" that the code stores in a variable somewhere.  It is also hard to explain to people that '&x' does not do what they want in that case, "& means address-of, and it returns a pointer here, what do you mean I can't use it?"
>> 
>> Using `inout` at the call site seems reasonable to me. I'd bet the vast majority of `inout` parameters are really the implicit `self` of mutating methods, which already get a pass, so aside from `swap` I wonder how often `&` is in practice.
> 
> One downside is that we do use '&' for things other than inout: pointers. If/when we do have a notion of "pass the stable address of this thing", 'inout' is not necessarily the most appropriate way to mark it.

This is the only concern I have with the current consensus.  We could just re-introduce & as an ordinary unary “assignment” operator, maybe.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/9464d856/attachment.html>