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

[Goffredo Marocchi]

Strong -1 from me as this adds unnecessary friction to the inout valid use case and does not add clarity/code self documentation. It would almost be better not to have anything at all at the call site (C++ like).

Sent from my iPhone

> On 30 Jan 2016, at 09:42, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1 from me as well, there’s no sense in using & for this instead as it’s just more confusing, plus switching it to inout could free it up for something else, or just leave it the sole domain of bitwise operations types.
> 
>> On 29 Jan 2016, at 23:02, Benedikt Terhechte via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> +1
>> 
>>> https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md
>>> 
>>> # Use `inout` at Function Call Sites * Proposal: TBD * Author(s): [Trent Nadeau](http://github.com/tanadeau) * Status: TBD * Review manager: TBD ## Introduction Currently when a function has `inout` parameters, the arguments are passed with the `&` prefix operator. For example: ```swift func add1(inout num: Int) {   num += 1 } var n = 5 add1(&n) // n is now 6 ``` This operator does not fit with the rest of the language nor how the parameter is written at the function declaration. It should be replaced so that `inout` is used in both locations so that the call site above would instead be written as: ```swift add1(inout n) // symmetric and now obvious that n can change ``` *Discussion thread TBD* ## Motivation 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 and introduces an unnecessary syntactic stumbling block from users coming from C. Removing this operator and using `inout` removes this stumbling block due to the semantic change. This operator is also disconnected from how the function declaration is written and does not imply that the argument may (and likely will) change. Using `inout` stands out, making it clear on first read that the variable may change. It is also possible that Swift may add Rust-like borrowing in the future. In that case, the `&` symbol would be better used for a borrowed reference. Note that Rust uses the same symbol for declaring a borrowed reference and creating one, creating a nice symmetry in that respect of the language. I think Swift would want to have such symmetry as well. ## Detailed design ``` in-out-expression → inout identifier ``` ## Alternatives Considered Keeping the syntax as it currently is.
>>> 
>>> --
>>> Trent Nadeau_______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution