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

[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 at swift.org> wrote:

> C# uses its `ref` keyword in both function declarations and call sites
> (see https://msdn.microsoft.com/en-us/library/14akc2c7.aspx), 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 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
>>
>>
>
>
> --
> Trent Nadeau
>
> _______________________________________________
> 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/b9ac6076/attachment.html>