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

[Trent Nadeau]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/f7935f43/attachment.html>