I agree 100% with everything Jordan said. -Kevin Ballard
On Sat, Dec 19, 2015, at 07:06 PM, Jordan Rose via swift-evolution wrote: > -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- >> [email protected]> 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- >>> [email protected]> wrote: >>> >>> >>>> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution <swift- >>>> [email protected]> 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 [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > _________________________________________________ > swift-evolution mailing list [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
