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

[Howard Lovatt]

+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
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
>>
>> Le 29 janv. 2016 à 17:44, Trent Nadeau via swift-evolution <
>> swift-evolution at swift.org
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Trent Nadeau
>


-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/1df53d80/attachment.html>