-1 to using '&' in the declaration; it's a sigil that doesn't mean anything as is. (I was originally on the side of using 'inout' at the call site as well, i.e. "swap(inout x, inout y)", but it was considered too verbose.)
I don't like it as an attribute because attributes generally don't affect the syntax of how something is used; they're mostly just implementation detail. Obviously they can have important semantics (like "@objc(…)" controlling the selector, or '@convention(c)' for C-compatible function pointers), but for the most part they don't change what the declaration is, whereas 'inout' definitely does. Given that we already use this syntax for function types when the parameter is unnamed, '(inout Int, inout named: Int) -> Void', I think Erica's first suggestion is my favorite so far. Jordan > On Dec 19, 2015, at 16:10 , Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > 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@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
