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

[Nate Birkholz]

+1

Sent from my iPhone, please excuse brevity and errors

> On Jan 29, 2016, at 3:05 PM, Jarod Long via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1 for the same reason.
> 
> Jarod
> 
>> On Jan 29, 2016, at 14:50, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> +1.  Really like the declaration and use symmetry.
>> 
>>> On Jan 29, 2016, at 4:48 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> +1.
>>> 
>>> -- E
>>> 
>>>> On Jan 29, 2016, at 3:44 PM, Trent Nadeau via swift-evolution <swift-evolution at 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:
>>>> 
>>>> ```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
>> 
>> _______________________________________________
>> 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/08364ddd/attachment.html>