[Proposal] Use inout at function call sites

Now that ++ and -- are gone, there are not any in the standard library. We do still have '!=' as an exception to the converse, though. :-) (And I've seen some operators in other libraries that don't have "=" but do mutate an argument.)

Jordan

···

On Jan 29, 2016, at 19:16 , Brent Royal-Gordon <brent@architechies.com> wrote:

P.S. At one point we thought about requiring you to declare "assignment" in your operator declaration, and disallowing inout parameters from arbitrary other operators, but that didn't actually turn into a proposal. It's not a bad idea, though—just a bit of compiler-enforced consistency.

Are there any `inout` operators which don't have `=` at the end of their name?

I'm not comfortable depending on implementation details for this sort of thing, but whatever floats your boat :).

I'd argue that replacing '&' with some other single-character sigil would preserve the conciseness benefit while reminding users that inout != pass-by-reference, but I have no idea which one to use and it seems like this proposal is close to DOA anyways.

Austin

···

On Jan 29, 2016, at 9:28 PM, Charles Kissinger <crk@akkyra.com> wrote:

On Jan 29, 2016, at 8:36 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

If I understand you correctly, I suspect inout's semantics may not line up with your use case.

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID545

The “As an optimization …” paragraph in the link explains why it works. I don’t see a problem with the semantics since it conceptually still makes a copy and passes back a modified one. It just fulfills the concept in a very efficient way. :-)

It may be unwise to depend on particular compiler optimizations, of course, but the Swift team has been pushing value semantics and copy-on-write, so it seems essential that those be supported efficiently. The alternative often is just to put a lot of code inline, which isn’t very appealing.

—CK

Sent from my iPhone

On Jan 29, 2016, at 7:57 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:

On Jan 29, 2016, at 5:57 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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:

- C-style multiple return, in which case it *should* be discouraged in the common case in favor of actual multiple return + tuple unpacking.
- 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.

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.

—CK

Best,
Austin

On Fri, Jan 29, 2016 at 5:40 PM, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
C# uses its `ref` keyword in both function declarations and call sites (see ref keyword - C# Reference - C# | Microsoft Learn), and I don't think people consider that syntax to be penalized or an edge case.

On Fri, Jan 29, 2016 at 8:32 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1

I feel like the people who are voting +1 probably don't actually use 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.

-Kevin Ballard

On Fri, Jan 29, 2016, at 02:44 PM, Trent Nadeau via swift-evolution wrote:

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\)
* Status: TBD
* Review manager: TBD

## Introduction

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

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:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Strong -1 from me as this adds unnecessary friction to the inout valid use case and does not add clarity/code self documentation. It would almost be better not to have anything at all at the call site (C++ like).

···

Sent from my iPhone

On 30 Jan 2016, at 09:42, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

+1 from me as well, there’s no sense in using & for this instead as it’s just more confusing, plus switching it to inout could free it up for something else, or just leave it the sole domain of bitwise operations types.

On 29 Jan 2016, at 23:02, Benedikt Terhechte via swift-evolution <swift-evolution@swift.org> wrote:

+1

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\) * 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 for me. Move inout to the type (Erica proposal) and use inout in the
same place at the call site. IE:

  func add(number n: inout Int)
   add(number: inout n)

···

On Saturday, 30 January 2016, Trent Nadeau via swift-evolution < swift-evolution@swift.org> wrote:

Note that I got this idea while thinking about Erica's proposal to move
the inout keyword to the type position in declarations. If that is
accepted, the difference between the inout locations would be eliminated.
So you examples would then be:

func add(number n: inout Int)
add(number: inout n)

func getUserData(id id: Int, name: inout String, gid: inout Int, shell:
inout String)
getUserData(id: userid, name: inout username, gid: inout groupid, shell:
inout shell)

On Fri, Jan 29, 2016 at 10:57 PM, Dany St-Amant via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Le 29 janv. 2016 à 17:44, Trent Nadeau via swift-evolution < >> swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> a écrit :

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\)
* Status: TBD
* Review manager: TBD

## Introduction

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

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

inout vs & doesn’t look that ugly in a simple single argument function,
but what if you have many:

getUserData(userid, &username, &groupid, &shell) // Current syntax
getUserData(userid, inout username, inout groupid, inout shell) //
Proposal

Yes, for the above one should use something better (
userData=getUserData(userid) ). But, I’m sure there are valid scenario
where one wants multiple inout parameters. And such an example must be
provided to visualize the impact of moving from & to inout.

Just realizing that the above syntax is without label, even the proposal
doesn’t show the use of the inout with labels…
So the current proposal changes:
add(number: &n)
to
add(inout number: n) // Perfect symmetry
add(number: inout n) // Matching token location

So with my bad example from above changing:
getUserData(id: userid, name: &username, gid: &groupid, shell: &shell)
to:
getUserData(id: userid, inout name: username, inout gid: groupid, inout
shell: shell)
getUserData(id: userid, name: inout username, gid: inout groupid, shell:
inout shell)

That’s a lot of word, syntax highlighting does help a bit but I do not
want to rely on it.

Dany

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
  -- Howard.

I'm not comfortable depending on implementation details for this sort of thing, but whatever floats your boat :).

Yes, I wouldn’t rely on it either if I knew of an alternative.

I was only trying to make the point that there are more use cases for functions with inout parameters than those you mentioned. It would be interesting to know how often inout *is* used by the community as a whole.

—CK

···

On Jan 29, 2016, at 9:33 PM, Austin Zheng <austinzheng@gmail.com> wrote:

I'd argue that replacing '&' with some other single-character sigil would preserve the conciseness benefit while reminding users that inout != pass-by-reference, but I have no idea which one to use and it seems like this proposal is close to DOA anyways.

Austin

On Jan 29, 2016, at 9:28 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:

On Jan 29, 2016, at 8:36 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

If I understand you correctly, I suspect inout's semantics may not line up with your use case.

The Swift Programming Language: Redirect

The “As an optimization …” paragraph in the link explains why it works. I don’t see a problem with the semantics since it conceptually still makes a copy and passes back a modified one. It just fulfills the concept in a very efficient way. :-)

It may be unwise to depend on particular compiler optimizations, of course, but the Swift team has been pushing value semantics and copy-on-write, so it seems essential that those be supported efficiently. The alternative often is just to put a lot of code inline, which isn’t very appealing.

—CK

Sent from my iPhone

On Jan 29, 2016, at 7:57 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:

On Jan 29, 2016, at 5:57 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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:

- C-style multiple return, in which case it *should* be discouraged in the common case in favor of actual multiple return + tuple unpacking.
- 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.

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.

—CK

Best,
Austin

On Fri, Jan 29, 2016 at 5:40 PM, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
C# uses its `ref` keyword in both function declarations and call sites (see ref keyword - C# Reference - C# | Microsoft Learn), and I don't think people consider that syntax to be penalized or an edge case.

On Fri, Jan 29, 2016 at 8:32 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1

I feel like the people who are voting +1 probably don't actually use 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.

-Kevin Ballard

On Fri, Jan 29, 2016, at 02:44 PM, Trent Nadeau via swift-evolution wrote:

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\)
* Status: TBD
* Review manager: TBD

## Introduction

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

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:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-1
& works perfectly fine.
Ondra

···

On Sat, Jan 30, 2016 at 7:28 AM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:

+1 for me. Move inout to the type (Erica proposal) and use inout in the
same place at the call site. IE:

  func add(number n: inout Int)
   add(number: inout n)

On Saturday, 30 January 2016, Trent Nadeau via swift-evolution < > swift-evolution@swift.org> wrote:

Note that I got this idea while thinking about Erica's proposal to move
the inout keyword to the type position in declarations. If that is
accepted, the difference between the inout locations would be eliminated.
So you examples would then be:

func add(number n: inout Int)
add(number: inout n)

func getUserData(id id: Int, name: inout String, gid: inout Int, shell:
inout String)
getUserData(id: userid, name: inout username, gid: inout groupid, shell:
inout shell)

On Fri, Jan 29, 2016 at 10:57 PM, Dany St-Amant via swift-evolution < >> swift-evolution@swift.org> wrote:

Le 29 janv. 2016 à 17:44, Trent Nadeau via swift-evolution < >>> swift-evolution@swift.org> a écrit :

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\)
* Status: TBD
* Review manager: TBD

## Introduction

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

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

inout vs & doesn’t look that ugly in a simple single argument function,
but what if you have many:

getUserData(userid, &username, &groupid, &shell) // Current syntax
getUserData(userid, inout username, inout groupid, inout shell) //
Proposal

Yes, for the above one should use something better (
userData=getUserData(userid) ). But, I’m sure there are valid scenario
where one wants multiple inout parameters. And such an example must be
provided to visualize the impact of moving from & to inout.

Just realizing that the above syntax is without label, even the proposal
doesn’t show the use of the inout with labels…
So the current proposal changes:
add(number: &n)
to
add(inout number: n) // Perfect symmetry
add(number: inout n) // Matching token location

So with my bad example from above changing:
getUserData(id: userid, name: &username, gid: &groupid, shell: &shell)
to:
getUserData(id: userid, inout name: username, inout gid: groupid, inout
shell: shell)
getUserData(id: userid, name: inout username, gid: inout groupid,
shell: inout shell)

That’s a lot of word, syntax highlighting does help a bit but I do not
want to rely on it.

Dany

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
  -- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Maybe that one use case should be turned into part of the 'formal specification', since it seems both useful and like something people would be inclined to assume anyways. Not sure what the ramifications would be. Maybe I'll start a pre-proposal thread.

Austin

···

On Jan 29, 2016, at 10:03 PM, Charles Kissinger <crk@akkyra.com> wrote:

On Jan 29, 2016, at 9:33 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

I'm not comfortable depending on implementation details for this sort of thing, but whatever floats your boat :).

Yes, I wouldn’t rely on it either if I knew of an alternative.

I was only trying to make the point that there are more use cases for functions with inout parameters than those you mentioned. It would be interesting to know how often inout *is* used by the community as a whole.

—CK

I'd argue that replacing '&' with some other single-character sigil would preserve the conciseness benefit while reminding users that inout != pass-by-reference, but I have no idea which one to use and it seems like this proposal is close to DOA anyways.

Austin

On Jan 29, 2016, at 9:28 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:

On Jan 29, 2016, at 8:36 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

If I understand you correctly, I suspect inout's semantics may not line up with your use case.

The Swift Programming Language: Redirect

The “As an optimization …” paragraph in the link explains why it works. I don’t see a problem with the semantics since it conceptually still makes a copy and passes back a modified one. It just fulfills the concept in a very efficient way. :-)

It may be unwise to depend on particular compiler optimizations, of course, but the Swift team has been pushing value semantics and copy-on-write, so it seems essential that those be supported efficiently. The alternative often is just to put a lot of code inline, which isn’t very appealing.

—CK

Sent from my iPhone

On Jan 29, 2016, at 7:57 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:

On Jan 29, 2016, at 5:57 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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:

- C-style multiple return, in which case it *should* be discouraged in the common case in favor of actual multiple return + tuple unpacking.
- 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.

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.

—CK

Best,
Austin

On Fri, Jan 29, 2016 at 5:40 PM, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
C# uses its `ref` keyword in both function declarations and call sites (see ref keyword - C# Reference - C# | Microsoft Learn), and I don't think people consider that syntax to be penalized or an edge case.

On Fri, Jan 29, 2016 at 8:32 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1

I feel like the people who are voting +1 probably don't actually use 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.

-Kevin Ballard

On Fri, Jan 29, 2016, at 02:44 PM, Trent Nadeau via swift-evolution wrote:

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\)
* Status: TBD
* Review manager: TBD

## Introduction

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

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:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution