<div dir="ltr">That fact that the &amp; operator is required for immutable pointers definitely makes this change not-so-great unless we add the pass by value for immutable.<div><br></div><div>For instance for C&#39;s memcpy which is defined in C as:</div><div><br></div><div><font face="monospace, monospace">void *memcpy(void *dest, const void *src, size_t n)</font><br></div><div><br></div><div>is imported into Swift as:</div><div><br></div><div><font face="monospace, monospace">public func memcpy(_: UnsafeMutablePointer&lt;Void&gt;, _: UnsafePointer&lt;Void&gt;, _: Int) -&gt; UnsafeMutablePointer&lt;Void&gt;</font><br></div><div><br></div><div>It would currently be called like:</div><div><br></div><div><div><font face="monospace, monospace">var src: Float = 5.3</font></div><div><font face="monospace, monospace">var dest: Float = 0.0</font></div><div><font face="monospace, monospace">memcpy(&amp;dest, &amp;src, sizeof(Float))</font></div></div><div><br></div><div>If we don&#39;t change how UnsafePointer is called and just replace &quot;&amp;&quot; with &quot;inout &quot;, then it becomes:</div><div><br></div><div><span style="font-family:monospace,monospace">memcpy(inout dest, inout src, sizeof(Float))</span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><font face="arial, helvetica, sans-serif">And now the &quot;src&quot; part of the call in now basically lying.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">If we can just pass src directly (assuming that&#39;s what you meant by pass-by-value), then it would be:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><span style="font-family:monospace,monospace">memcpy(inout dest, src, sizeof(Float))</span><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">which seems nicer than both the previous versions.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Would the UnsafePointer change need to be a proposal that is a predecessor to this one?</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">P.S. It would be nice to be able to pass constants to UnsafePointer and not using &quot;&amp;&quot; for inout and UnsafePointer would allow that I think.</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 6:23 PM, Jordan Rose <span dir="ltr">&lt;<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>+1 from me, but I suggest finding some real-world examples of inout (and UnsafePointer) and showing those, rather than a made-up add1. The fact that we currently require &#39;&amp;&#39; for Unsafe-(immutable)-Pointer might make this a bit less nice than it otherwise would be.</div><div><br></div><div>(We&#39;ve talked about allowing pass-by-value for UnsafePointer, but that has its own pros and cons, and should be discussed separately.)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Jordan</div><div><br></div><br></font></span><div><blockquote type="cite"><div><div class="h5"><div>On Jan 29, 2016, at 14:44, Trent Nadeau via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr"><a href="https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md" target="_blank">https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md</a><div><br></div><div><pre># Use `inout` at Function Call Sites

* Proposal: TBD
* Author(s): [Trent Nadeau](<a href="http://github.com/tanadeau" target="_blank">http://github.com/tanadeau</a>)
* Status: TBD
* Review manager: TBD

## Introduction

Currently when a function has `inout` parameters, the arguments are passed with the `&amp;` prefix operator. For example:

```swift
func add1(inout num: Int) {
    num += 1
}

var n = 5
add1(&amp;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 `&amp;` prefix operator is a holdover from C where it is usually read as &quot;address of&quot; 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 `&amp;` 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><br></div>-- <br><div>Trent Nadeau</div>
</div></div></div></div><span class="">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Trent Nadeau</div>
</div>