[swift-evolution] [Pitch] Replace 'inout' with '&'

[Erica Sadun]

What would the ramifications of the following be? Each addresses the "confusable with labeling" issue but preserve the inout keyword.

func foo(x: inout Int)
func foo(x: @inout(Int))
func foo(x: @inout Int)

Is there an underlying reason that parameter modification should live on the name side rather than the type side of the colon? They aren't really modifying the name

-- Erica, inexperienced with Rust


> On Dec 18, 2015, at 7:07 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> For Swift 3, we're planning to phase out 'var' parameters in functions, and we're also making it so that language keywords are valid argument labels. With both of these changes pending, I have a hard time not reading:
>> 
>> func foo(inout x: Int)
>> 
>> as an argument labeled `inout` instead of an unlabeled argument bound to `x`. Once `var` is phased out, `inout` would also be the only remaining case where quoting is necessary to use a name as an argument label. The `inout` keyword has always struck me as weird, since it violates definition-follows-use—maybe we should replace it with the `&` sigil, mirroring its usage in call sites.
> 
> -1
> 
> “inout” is intended to communicate (or at least hint at) the copy-in / copy-out behavior of the argument.  It is also there to enable other parameter modifiers, which can enable other more advanced parameters models in the future (e.g. rust-style borrowing).
> 
> -Chris
> 
> 
> _______________________________________________
> 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/20151219/d5e7dcb7/attachment.html>