<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="">On Apr 20, 2016, at 10:18 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Obviously, given a name to the parameter brings clarity and can be self documenting, but if we want the above to work while making names just as vital as the type signature, then we need to declare `Functor` as such:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">typealias Functor = (_ left: Int, _ right: Int) -> Int</font></div></div></blockquote><div class=""><br class=""></div><div class="">However, that's not even legal code today, and even if it were, is that really better?</div></div></div></blockquote></div><br class=""><div class="">I don’t think this follows, since operator parameters are always unlabeled. I suspect we don’t reject it, but I’d be in favor of rejecting:</div><div class=""><br class=""></div><div class="">func +(lhs <b class="">xyz</b>: Int, rhs <b class="">abc</b>: Int) -> Int { }</div></div></div></blockquote><div class=""><br class=""></div></div>So maybe I think about this incorrectly, but I always think of any parameter without an explicit label to have one that is equal to the parameter name. </div></div></blockquote><div><br class=""></div><div>We’re going in that direction, but that is not currently the case for operators and subscript indices. As a community, we don’t have much real-world experience using Swift 3, but I don’t expect that either of those cases would get better by requiring labels by default and requiring _ to suppress them.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">So these two functions signatures would be equivalent:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Menlo" class="">func sum1(lhs: Int, rhs: Int) -> Int</font></div><div class=""><div class=""><font face="Menlo" class="">func sum2(lhs lhs: Int, rhs rhs: Int) -> Int</font></div></div><div class=""><font face="Menlo" class=""><br class=""></font></div></blockquote>It’s only when you explicit “erase” the label where there is none:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">func sum(_ lhs: Int, _ rhs: Int) -> Int</font></div></div><div class=""><font face="Menlo" class=""><br class=""></font></div></blockquote><div class=""><div class=""></div></div><div class="">So back to the example above, it’s still somewhat odd that all of these are valid:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Menlo" class="">hi(1, y: 2, fn: sum1)</font></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><span style="font-family: Menlo;" class="">hi(1, y: 2, fn: sum2)</span></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><span style="font-family: Menlo;" class="">hi(1, y: 2, fn: sum) // makes the most sense, no label to labeled promotion</span></blockquote><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">But if we did reject the differently labeled version, that would mean that we would need to declare the `Functor` above as:</div><div class=""><br class=""></div><div class=""><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class="">typealias Functor = (Int, Int) -> Int</font></blockquote></div></div></div></blockquote><div><br class=""></div><div>I agree that eliminating relabeling would force this. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Is that better? I’m not terribly convinced that it is.</div></div></div></blockquote><div><br class=""></div><div>Me neither.</div><div><br class=""></div>Off in crazy space for a bit, but one could argue that this style of design would imply that you should be able to call this example like this:<br class=""><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><font face="Menlo" class="">hi(1, y: 2, fn: { sum1(lhs: $left, rhs: $right) })</font></blockquote></div></div></div></blockquote><br class=""></div><div>since the only sensible names for the parameters come from context.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>