[swift-evolution] [Proposal] Use inout at function call sites

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

On Fri, Jan 29, 2016, at 06:39 PM, Jordan Rose wrote:
> Can you show us some examples? I remember your replace(_:with:); what
> else do you use?
>
> Jordan
>
>> On Jan 29, 2016, at 17:32 , Kevin Ballard via swift-evolution <swift-
>> evolution at 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:

```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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/9222b251/attachment.html>