Me too. -Chris
> On Dec 21, 2015, at 10:44 AM, Kevin Ballard via swift-evolution > <[email protected]> wrote: > > 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 >>> <[email protected] <mailto:[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 >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution >>>>> <[email protected] <mailto:[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] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
