> On Dec 21, 2015, at 10:27 , Joe Groff <[email protected]> wrote: > > >> On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> On Sat, Dec 19, 2015 at 7:06 PM, Jordan Rose via swift-evolution >> <[email protected] <mailto:[email protected]>> 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. Then again, if something has a stable address, you're not limited to getting its address using a call. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
