<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>If I understand you correctly, I suspect inout's semantics may not line up with your use case. </div><div><br></div><div><a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID545">https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID545</a><br><br><div>Sent from my iPhone</div></div><div><br>On Jan 29, 2016, at 7:57 PM, Charles Kissinger <<a href="mailto:crk@akkyra.com">crk@akkyra.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2016, at 5:57 PM, Austin Zheng 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="">Personal opinion: +1 to the proposal. Would rather '&' be available for other language features. `inout` is a legitimate language feature, but not in my opinion one important enough to consume that sigil. It serves two purposes:<div class=""><br class=""></div><div class="">- C-style multiple return, in which case it *should* be discouraged in the common case in favor of actual multiple return + tuple unpacking.</div><div class="">- Interoperability with C APIs, but some degree of cumbersomeness is already to be expected given how C features map to Swift features. Plus, this use case makes the semantic mismatch problem more pronounced since one would naturally be tempted to ascribe C semantics to a superficially C-like feature being used to interop with C APIs.</div></div></div></blockquote><div><br class=""></div><div>I’ve actually never used ‘inout’ for either of the purposes you mention. I do use it for modifying large copy-on-write data structures in situations where it will allow the compiler to minimizing copying. I think that’s a common, mainstream use.</div><div><br class=""></div>—CK</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 29, 2016 at 5:40 PM, 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="">C# uses its `ref` keyword in both function declarations and call sites (see <a href="https://msdn.microsoft.com/en-us/library/14akc2c7.aspx" target="_blank" class="">https://msdn.microsoft.com/en-us/library/14akc2c7.aspx</a>), and I don't think people consider that syntax to be penalized or an edge case.</div><div class="gmail_extra"><div class=""><div class="h5"><br class=""><div class="gmail_quote">On Fri, Jan 29, 2016 at 8:32 PM, Kevin Ballard 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"><u class=""></u>
<div class=""><div class="">-1<br class=""></div>
<div class=""> </div>
<div class="">I feel like the people who are voting +1 probably don't actually <i class="">use</i> inout parameters very often, because it seems very obvious that requiring the label "inout" at the function call site is extremely unwieldy. inout parameters aren't some weird edge case that we want to penalize, they're a perfectly legitimate feature of the language, and they should be relatively easy to call.<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard<br class=""></div><div class=""><div class="">
<div class=""> </div>
<div class="">On Fri, Jan 29, 2016, at 02:44 PM, Trent Nadeau via swift-evolution wrote:<br class=""></div>
</div></div><blockquote type="cite" class=""><div class=""><div class=""><div dir="ltr" class=""><div 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><br class=""></div>
<div 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.<br class=""></pre><div class=""> </div>
<div class="">-- <br class=""></div>
<div class="">Trent Nadeau<br class=""></div>
</div>
</div>
</div></div><span class=""><div class=""><u class="">_______________________________________________</u><br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</span></blockquote><div class=""> </div>
</div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" 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=""><br clear="all" class=""><div class=""><br class=""></div></div></div><span class="HOEnZb"><font color="#888888" class="">-- <br class=""><div class="">Trent Nadeau</div>
</font></span></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></body></html>