<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">As has been discussed exhaustively in this thread, Swift 3 function labels don't convey the meaning of parameters, they are almost always prepositional phrases that don't make sense apart from the primary function name they are attached to.</span></div></blockquote></div><div class="">Why should there be different rules for closures and regular functions?</div><div class="">If labels are considered useful, they are useful in both contexts, and it should not be forbidden to have labels for closure parameters.</div><div class=""><br class=""></div><div class="">The only thing I don't like now is that labels are added when the type is inferred; imho that doesn't make sense in deed, and it would be more consistent to strip them (when labels are part of the name, this is like silently changing variable names to match Hungarian notation ;-).</div><div class=""><br class=""></div><div class="">I'd hardly oppose anything that simplifies the type system, so I agree with Brent that it is ok to remove them first to re-introduce them in a better form later.</div></body></html>