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

[Ondrej Barina]

-1
& works perfectly fine.
Ondra

On Sat, Jan 30, 2016 at 7:28 AM, Howard Lovatt via swift-evolution <
swift-evolution at 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 at 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 at swift.org> wrote:
>>
>>>
>>> Le 29 janv. 2016 à 17:44, Trent Nadeau via swift-evolution <
>>> swift-evolution at 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:
>>>
>>> ```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
>>>
>>>
>>> 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>
>> --
>> Trent Nadeau
>>
>
>
> --
>   -- Howard.
>
>
> _______________________________________________
> 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/20160130/60492a26/attachment.html>