<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Big -1 from me.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 4:35 PM, Allen Ding via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>I would go even farther than this. An important part of reading through code is determining: is this a declaration or a statement/expression? I.e. am I defining terminology or actually doing things right now? Having call site and declaration look too much like the other is positively a bad thing.</div><div><br class=""></div><div>In this case, “inout” looks okay in normal declaration syntax, but ```add1(inout n)``` doesn’t look like a statement because ```inout n``` doesn’t look like an expression, because inout doesn’t look like either a prefix operator or a function application. This proposal adds an entirely new class of stuff (an extra identifier — a word) that can be thrown into a place that usually looks like and follows the syntactic rules for expressions, and I think that that adds FAR more confusion than it removes.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Greg<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Sat, Jan 30, 2016 at 6:44 AM, Trent Nadeau via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><a href="https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md" target="_blank" class="">https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md</a><div class=""><br class=""></div><div class=""><pre style="" class=""># Use `inout` at Function Call Sites
* Proposal: TBD
* Author(s): [Trent Nadeau](<a href="http://github.com/tanadeau" target="_blank" class="">http://github.com/tanadeau</a>)
* 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.</pre><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div>-- <br class=""><div class="">Trent Nadeau</div>
</font></span></div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>