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

[Jordan Rose]

[ Proposal link: https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md <https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md> ]

My issue is that '&' and 'inout' really don't have anything to do with each other, and that '&' doesn't inherently mean anything related to what's going on here unless you've used C. (Or C++, or Objective-C, or C#…or Go, or Rust. But not Python, Java, JavaScript, or Ruby <http://www.skorks.com/2013/04/ruby-ampersand-parameter-demystified/>.) And & doesn't actually do the same thing as it does in any of those languages; it does something that already has a name in Swift, which is 'inout'.

This thing only needs one name, and of the two it has, 'inout' is the better one. +1 from me.
Jordan


> On Jan 29, 2016, at 16:35 , Allen Ding via swift-evolution <swift-evolution at swift.org> wrote:
> 
> My 2 cents.
> 
> 1. At the use site (and in actual usage in my code), func(&value) is a visually recognizable enough pattern that it is "obvious" when I read it.
> 
> 2. At the call use, func(inout value) would also be obvious, but feels clunkier and may even be less immediately recognizable. Just my opinion. I find symbols easier to pick out when reading.
> 
> 3. I really need to be convinced that symmetry of usage at call site (for any language feature) and declaration is a desirable thing. In my opinion, declaration and use are orthogonal things and a lot of Swift already exhibits this asymmetry. e.g. parameter labels vs argument names, why doesn't calling a mutating func require mutating somewhere in the call to make it obvious the call might mutate the receiver.
> 
> 4. The possibility of Swift becoming more Rust-like and letting this possibility drive this discussion does not seem like it should factor into the discussion of whether this proposal is a win.
> 
> 
> On Sat, Jan 30, 2016 at 6:44 AM, Trent Nadeau via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md <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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/a8a244f3/attachment.html>