<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="">I see the appeal of this, but I’m still against.</div><div class=""><br class=""></div><div class="">I like that:</div><div class="">- it’s symmetric between definition and use site</div><div class="">- it avoids ambiguity with C’s semantics of &</div><div class="">- it conveys the opinion that this isn’t a fundamental feature of Swift you should use all the time, only when needed.</div><div class=""><br class=""></div><div class="">Still, `inout n` at call site is ugly and kind of unreadable in my opinion. “&” stands out immediately, telling you “hey, this isn’t a normal call — this can change n’s contents!”. It’s a warning hard to miss while skimming code. “inout”, being a word, just gets drowned in between all the other words. This is compounded by the fact there isn’t any precedent (unless I’m missing something) of using a keyword as a modifier in function call syntax like that, and that this isn’t a particularly common one.</div><div class=""><br class=""></div><div class="">So an prefix operator-like syntax is just clearer. Unless it really is confusing because of what it means in C. But I don’t find this argument compelling. Perhaps if I spent a lot more time using C and developed a very strong mental model of how it works, I would. But from my limited experience with C, and only using it sparingly in ObjC, it doesn’t confuse me at all. Having the same symbol suggests there is some similarity (and there is!), but I had no problem “getting” the Swift meaning. Perhaps what helps is that Ruby also has a prefix & operator, also meaning something else.</div><div class=""><br class=""></div><div class="">And, while I like the idea of making it look like a second-class citizen because it’s not _that_ common on some level, I also tend to agree with Kevin that this is a perfectly useful feature and we shouldn’t penalize it this much.</div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 29 Jan 2016, at 23:44, Trent Nadeau via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><a href="https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md" 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" 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><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Trent Nadeau</div>
</div></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>