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> 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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
