> On Dec 21, 2015, at 11:19 AM, Jordan Rose via swift-evolution
> <swift-evolution@swift.org> wrote:
>> On Dec 21, 2015, at 10:27 , Joe Groff <jgr...@apple.com
>> <mailto:jgr...@apple.com>> wrote:
>>
>>
>>> On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> On Sat, Dec 19, 2015 at 7:06 PM, Jordan Rose via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
