<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">func foo(inout x: Int)</div><div class=""><br class=""></div></blockquote>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.</div></div></blockquote><br class=""></div><div>-1</div><div><br class=""></div><div>“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).</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>