[Proposal] Use inout at function call sites

[Allen_Ding]

My 2 cents.

1. At the use site (and in actual usage in my code), func(&value) is a
visually recognizable enough pattern that it is "obvious" when I read it.

2. At the call use, func(inout value) would also be obvious, but feels
clunkier and may even be less immediately recognizable. Just my opinion. I
find symbols easier to pick out when reading.

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.

4. The possibility of Swift becoming more Rust-like and letting this
possibility drive this discussion does not seem like it should factor into
the discussion of whether this proposal is a win.

···

On Sat, Jan 30, 2016 at 6:44 AM, Trent Nadeau via swift-evolution < swift-evolution@swift.org> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

I started poking around. It looks like the rules for calls with functions are different from those with operators. At least in the following example, the operator version doesn't need the &. Any idea why?

Seems I'm to late with the answer — but at least my theory was right:
Assignment-operators would look ugly (imagine all those "inout x = y" ;-)

For me, it would be ok if inout parameters had no special syntax at all — afaik, "&" is just a hint for the possible mutation which could be highlighted typographically (but I'm rather fearless and trust in methods I'm calling :)

Summary:
-1

Tino

[Radek_Pietruszewski]

I see the appeal of this, but I’m still against.

I like that:
- it’s symmetric between definition and use site
- it avoids ambiguity with C’s semantics of &
- it conveys the opinion that this isn’t a fundamental feature of Swift you should use all the time, only when needed.

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.

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.

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.

— Radek

···

On 29 Jan 2016, at 23:44, Trent Nadeau via swift-evolution <swift-evolution@swift.org> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

[Austin (Austin Zheng)]

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.

Best,
Austin

···

On Fri, Jan 29, 2016 at 5:40 PM, Trent Nadeau via swift-evolution < 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> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

--
Trent Nadeau

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

[jrose (Jordan Rose)]

[ Proposal link: https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md ]

My issue is that '&' and 'inout' really don't have anything to do with each other, and that '&' doesn't inherently mean anything related to what's going on here unless you've used C. (Or C++, or Objective-C, or C#…or Go, or Rust. But not Python, Java, JavaScript, or Ruby <http://www.skorks.com/2013/04/ruby-ampersand-parameter-demystified/&gt;\.\) And & doesn't actually do the same thing as it does in any of those languages; it does something that already has a name in Swift, which is 'inout'.

This thing only needs one name, and of the two it has, 'inout' is the better one. +1 from me.
Jordan

···

On Jan 29, 2016, at 16:35 , Allen Ding via swift-evolution <swift-evolution@swift.org> wrote:

My 2 cents.

1. At the use site (and in actual usage in my code), func(&value) is a visually recognizable enough pattern that it is "obvious" when I read it.

2. At the call use, func(inout value) would also be obvious, but feels clunkier and may even be less immediately recognizable. Just my opinion. I find symbols easier to pick out when reading.

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.

4. The possibility of Swift becoming more Rust-like and letting this possibility drive this discussion does not seem like it should factor into the discussion of whether this proposal is a win.

On Sat, Jan 30, 2016 at 6:44 AM, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

[Brent_Royal-Gordon]

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?

···

--
Brent Royal-Gordon
Architechies

[Lily_Ballard]

replace(_:with:) is probably where I use inout the most often (and I think requiring the keyword `inout` instead of & makes that much more cumbersome). Other examples of uses of stdlib APIs are calling decode() on any of the UnicodeCodecType types (I have multiple different pieces of code that does this with UTF8), passing a target stream to print(), invoking isUniquelyReferenced() or isUniquelyReferencedNonObjC() (where taking an inout parameter already is just an implementation detail, and having to write `inout` when calling it makes it even weirder), or calling swap(). And every now and then I do write other once-off functions/methods that use inout (for example, I have an implementation of SipHash, and it uses a helper function called u8to64_le() that takes an inout parameter).

The basic point I'm trying to make, though, is that requiring the use of
`inout` at the call site only serves to discourage people from writing
new functions that take inout parameters, because it makes calling them
more awkward, but inout is a perfectly legitimate feature that doesn't
deserve to be discouraged. It may not be used all that often, but by the
same argument people don't run into & very often.

And FWIW, if we do ever add Rust-like borrowing, then `inout` would
presumably be replaced entirely with the equivalent of `&mut`, which
means that argument isn't compelling because we'd just end up switching
all those calls that pass `inout x` right back to `&x` or `&mut x`.

-Kevin Ballard

Can you show us some examples? I remember your replace(_:with:); what
else do you use?

Jordan

-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

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:

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\.

<details class='elided'>
<summary title='Show trimmed content'>&#183;&#183;&#183;</summary>

On Fri, Jan 29, 2016, at 06:39 PM, Jordan Rose wrote:
>> On Jan 29, 2016, at 17:32 , Kevin Ballard via swift\-evolution &lt;swift\- &gt;&gt; evolution@swift\.org&gt; wrote:
>> On Fri, Jan 29, 2016, at 02:44 PM, Trent Nadeau via swift\- &gt;&gt; evolution wrote:
>>>
>>> \-\-
>>> 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

</details>

[Trent_Nadeau]

1. This is an opinion where people may disagree. However, the confusion
   with C semantics and how they do actually interact with Swift is important
   here, as Dmitri, Jordan, and Joe mentioned above.
   2. See above. Given the semantics confusion, I and others think we
   should have something different. If we need a different way to express
   that, having symmetry between the declaration and use seems like it could
   be a good pick.
   3. It's true there is already asymmetry in this area. However, I don't
   think we should have such if we can avoid it. Mutating functions, at least,
   have compiler errors to find out where you're misusing them such as calling
   one on a constant value type. Parameter labels vs. argument names require,
   I think, an unavoidable divergence in grammar due to have 1-2 names in one
   place and 0-1 names in the other.
   4. Allowing Rust-like borrowing is not the main reason for this
   proposal, the symmetry and avoidance of confusing semantics are. However,
   freeing up the & symbol would more easily allow for a feature that I and
   others (including Chris Lattner) think would be very useful, especially in
   constrained environments. One of the promises of future Swift is to stretch
   from systems programming to scripting.

···

On Fri, Jan 29, 2016 at 7:35 PM, Allen Ding <allen@snappymob.com> wrote:

My 2 cents.

1. At the use site (and in actual usage in my code), func(&value) is a
visually recognizable enough pattern that it is "obvious" when I read it.

2. At the call use, func(inout value) would also be obvious, but feels
clunkier and may even be less immediately recognizable. Just my opinion. I
find symbols easier to pick out when reading.

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.

4. The possibility of Swift becoming more Rust-like and letting this
possibility drive this discussion does not seem like it should factor into
the discussion of whether this proposal is a win.

On Sat, Jan 30, 2016 at 6:44 AM, Trent Nadeau via swift-evolution < > swift-evolution@swift.org> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

[Charles_Kissinger]

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

···

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

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

[jrose (Jordan Rose)]

This is already true. Are you thinking of something else?

Jordan

···

On Jan 29, 2016, at 19:45 , Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

add1(&n) // n is now 6
add1(inout n) // symmetric and now obvious that n can change

I'm not a really big fan of this change; despite being longer, `inout n` is less visible to me than `&n`. But this is a relatively weak preference—I could certainly live with it.

More important than changing the symbol might be restricting its use. I don't see any particularly good reason to permit you to say `let x = &y`. Far better to use `withUnsafePointer()` to control the scope of the pointer, or at least say something like `let x = unsafeInoutPointer(&y)` to acknowledge that you're circumventing memory safety and possibly taking a pointer to a temporary. Basically, I think `&` or `inout` or however we spell it should only be allowed as a parameter, not just anywhere in any expression.

[Austin (Austin Zheng)]

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

···

Sent from my iPhone

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

On Jan 29, 2016, at 5:57 PM, Austin Zheng via swift-evolution <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> 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> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

--
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

[Chris_Lattner]

My 2 cents.

1. At the use site (and in actual usage in my code), func(&value) is a visually recognizable enough pattern that it is "obvious" when I read it.

I agree.

2. At the call use, func(inout value) would also be obvious, but feels clunkier and may even be less immediately recognizable. Just my opinion. I find symbols easier to pick out when reading.

I agree, we actually evaluated this sometime between Swift 1 and Swift 2 and converted actual code using & to using inout on the call site, it looked worse. Clarity suffered, particularly when a parameter had an argument label.

Keep in mind that we’re forcing this syntax on the caller side of things *only* to make it clear that something indirect is happening. There is no implementation reason to need this, it is to increase clarity. I am very concerned that making that “high pain” of such a sentinel would make defeat the purpose of this design decision in the first place.

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.

Agreed.

4. The possibility of Swift becoming more Rust-like and letting this possibility drive this discussion does not seem like it should factor into the discussion of whether this proposal is a win.

Agreed. As a concrete example of this, people frequently ask for “in” and “out” parameters. With the current design, the call site would both use & for inout, in, and out. If we went with this proposal, we’d have to use in and out on the call side as well, which forces taking “out” as a keyword.

Another problem with this is that this would break imported UnsafePointer’s, because it wouldn’t make sense to pass a “const char*” as “inout”. We’d be forced to design “in” parameters as a prerequisite for this feature.

Another problem with this proposal is that it gets *unbearably* ugly if we end up with inout (and its future friends) being turned into attributes. Do you really want to see:

swap(@inout x, @inout y)

? Is that making code better somehow?

Overall, I am very -1 on this proposal, for many of the reasons that Allen cites. This is a “seemingly obvious” proposal (which has come up many times before) which is pretty bad in practice.

-Chris

···

On Jan 29, 2016, at 4:35 PM, Allen Ding via swift-evolution <swift-evolution@swift.org> wrote:

[Charles_Kissinger]

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

···

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

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

[Trent_Nadeau]

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

[possen (Paul Ossenbruggen)]

-1 to this proposal. I don’t think the symmetry is big enough of a win. We just need some way of indicating that the param is different at the call site, most of the suggestions are less concise, or different without much benefit in clarity.

It might be nice to free up & for other purposes than just a marker for an inout parameter is the only reason I might think it a change here might be good because it is underutilized, this is the only place & is used that I am aware of, unlike C where it is used in many places for taking the address of something.

[griotspeak (TJ Usiyan)]

+1 for the added symmetry and searchability

···

On Sat, Jan 30, 2016 at 4:45 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> add1(&n) // n is now 6
> add1(inout n) // symmetric and now obvious that n can change

I'm not a really big fan of this change; despite being longer, `inout n`
is less visible to me than `&n`. But this is a relatively weak preference—I
could certainly live with it.

More important than changing the symbol might be restricting its use. I
don't see any particularly good reason to permit you to say `let x = &y`.
Far better to use `withUnsafePointer()` to control the scope of the
pointer, or at least say something like `let x = unsafeInoutPointer(&y)` to
acknowledge that you're circumventing memory safety and possibly taking a
pointer to a temporary. Basically, I think `&` or `inout` or however we
spell it should only be allowed as a parameter, not just anywhere in any
expression.

--
Brent Royal-Gordon
Architechies

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

[Greg_Titus]

Big -1 from me.

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.

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.

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.

  - Greg

···

On Jan 29, 2016, at 4:35 PM, Allen Ding via swift-evolution <swift-evolution@swift.org> wrote:

On Sat, Jan 30, 2016 at 6:44 AM, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

[Haravikk3 (Haravikk)]

+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

[Trent_Nadeau]

Chris, thanks for your feedback. If Apple tried this idea internally and it
didn't work out, then that's probably reason enough to abandon my proposal.

Do you think this (along with `in` and `out` params) should be added to the
rejected list? If so, I can add it based on your and others' comments.

···

On Fri, Jan 29, 2016 at 11:38 PM, Chris Lattner <clattner@apple.com> wrote:

On Jan 29, 2016, at 4:35 PM, Allen Ding via swift-evolution < > swift-evolution@swift.org> wrote:
> My 2 cents.
>
> 1. At the use site (and in actual usage in my code), func(&value) is a
visually recognizable enough pattern that it is "obvious" when I read it.

I agree.

> 2. At the call use, func(inout value) would also be obvious, but feels
clunkier and may even be less immediately recognizable. Just my opinion. I
find symbols easier to pick out when reading.

I agree, we actually evaluated this sometime between Swift 1 and Swift 2
and converted actual code using & to using inout on the call site, it
looked worse. Clarity suffered, particularly when a parameter had an
argument label.

Keep in mind that we’re forcing this syntax on the caller side of things
*only* to make it clear that something indirect is happening. There is no
implementation reason to need this, it is to increase clarity. I am very
concerned that making that “high pain” of such a sentinel would make defeat
the purpose of this design decision in the first place.

> 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.

Agreed.

> 4. The possibility of Swift becoming more Rust-like and letting this
possibility drive this discussion does not seem like it should factor into
the discussion of whether this proposal is a win.

Agreed. As a concrete example of this, people frequently ask for “in” and
“out” parameters. With the current design, the call site would both use &
for inout, in, and out. If we went with this proposal, we’d have to use in
and out on the call side as well, which forces taking “out” as a keyword.

Another problem with this is that this would break imported
UnsafePointer’s, because it wouldn’t make sense to pass a “const char*” as
“inout”. We’d be forced to design “in” parameters as a prerequisite for
this feature.

Another problem with this proposal is that it gets *unbearably* ugly if we
end up with inout (and its future friends) being turned into attributes.
Do you really want to see:

swap(@inout x, @inout y)

? Is that making code better somehow?

Overall, I am very -1 on this proposal, for many of the reasons that Allen
cites. This is a “seemingly obvious” proposal (which has come up many
times before) which is pretty bad in practice.

-Chris

--
Trent Nadeau

[Lily_Ballard]

++ and -- come to mind, although they're being deprecated.

-Kevin Ballard

···

On Fri, Jan 29, 2016, at 07:16 PM, Brent Royal-Gordon via swift-evolution 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?