<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=""><div class="">Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a></div><br class="">Shortly after SE-0111 was accepted last week, several people newly noticed the proposal and started a discussion about how it appears to be a regression for closure parameters (e.g. callbacks) that could formerly carry labels, but are now not allowed to. These folks observed that it would be more expressive (and consistent with the rest of Swift) to allow parameter labels in function types, because the invocation site of a closure “should" be required to provide those labels. The core team has been following the discussion, agrees that this is a concern, and wants to update the community with a path forward.<div class=""><br class=""></div><div class="">The reality of the situation is that the current implementation of parameter labels in function types is inherently broken. Specifically, as one example, there is an implicit conversion from "<font face="Menlo" class="">(a: Int) -> Int</font>” to “<font face="Menlo" class="">(Int) -> Int</font>”. However, there is also an implicit conversion from "<font face="Menlo" class="">(Int) -> Int</font>” to “<font face="Menlo" class="">(b : Int) -> Int</font>”. This means that the compiler currently allows converting from “<font face="Menlo" class="">(a: Int) -> Int</font>” to “<font face="Menlo" class="">(b: Int) -> Int</font>”, which doesn’t make sense, introduces surprising behavior, introduces complexity into the compiler implementation, and is generally a problem. We do have one specific hack to prevent conversion of (e.g.) “<font face="Menlo" class="">(a : Int, b : Int) -> Void</font>” to “<font face="Menlo" class="">(b : Int, a : Int) -> Void</font>”, but this only triggers in specific cases. There are other more complex cases as well, e.g. when using generics "<font face="Menlo" class="">T<(a : Int)->Int></font>” cannot be considered compatible with "<font face="Menlo" class="">T<(b : Int)->Int></font>”.</div><div class=""><br class=""></div><div class="">These problems are what initially motivated SE-0111. However, given the feedback, the core team went back to the drawing board to determine whether: a) SE-0111 by itself is the right long term answer, b) whether there were alternate models that could solve the same problems in a different way, or c) whether SE-0111 was the right first step to "ultimate glory" in the field of closure parameter labels. After a long discussion, and many alternatives considered, the core team believes in c), that SE-0111 (with a minor modification) is the right step for Swift 3, because it paves the way for the right model over the long term.</div><div class=""><br class=""></div><div class="">----8<----</div><div class=""><br class=""></div><div class="">The specific revision requested by the core team to SE-0111 is that all “cosmetic” labels should be required to include an API name of _. For example, this would not be allowed:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> var op : (lhs : Int, rhs : Int) -> Int</font></div><div class=""><br class=""></div><div class="">instead, it should be spelled as:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> var op : (_ lhs : Int, _ rhs : Int) -> Int</font></div></div><div class=""><br class=""></div><div class="">With this change, we believe that we have paved the way for a purely additive proposal (and thus, post-Swift 3) that will restore the expressive capability of closures with parameter labels. </div><div class=""><br class=""></div><div class=""><div class=""><div class="">----8<----</div></div></div><div class=""><br class=""></div><div class="">Here is a sketch of how that would work, in two steps:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">First, we extend declaration names for variables, properties, and parameters to allow *parameter names* as part of their declaration name. For example:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class=""> var op(lhs:,rhs:) : (Int, Int) -> Int // variable or property.</font></div><div class=""><font face="Menlo" class=""> x = op(lhs: 1, rhs: 2) // use of the variable or property.</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.</font></div><div class=""><font face="Menlo" class=""> func foo(opToUse op(lhs:,rhs:) : (Int, Int) -> Int) {</font></div><div class=""><div class=""><font face="Menlo" class=""> x = op(lhs: 1, rhs: 2) // use of the parameter</font></div></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class=""> foo(opToUse: +) // call of the function</font></div><div class=""><br class=""></div><div class="">This will restore the ability to express the idea of a closure parameter that carries labels as part of its declaration, without requiring parameter labels to be part of the type system (allowing, e.g. the operator + to be passed into something that requires parameter labels).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Second, extend the rules for function types to allow parameter API labels *if and only if* they are used as the type of a declaration that allows parameter labels, and interpret them as a sugar form for providing those labels on the underlying declaration. This means that the example above could be spelled as:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> var op : (lhs: Int, rhs: Int) -> Int // Nice declaration syntax</font></div><div class=""><font face="Menlo" class=""> x = op(lhs: 1, rhs: 2) // Same as above</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.</font></div><div class=""><font face="Menlo" class=""> func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {</font></div><div class=""><font face="Menlo" class=""> x = op(lhs: 1, rhs: 2) // Same as above.</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class=""> foo(opToUse: +) // </font><span style="font-family: Menlo;" class="">Same as above.</span></div></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><br class=""></div><div class="">These two steps will provide the simple and expressive design approach that we have now, without all of the problems that representing parameter labels in the type system introduces. The core team believes that the temporary regression in expressiveness is an acceptable loss for Swift 3, particularly given that this will have no impact on Cocoa or the standard library. In the case of Cocoa, recall that C and Objective-C don’t have parameter labels on their corresponding concepts (Blocks and C function pointers), and the higher order functions in the standard library should not require parameter labels either.</div><div class=""><br class=""></div><div class="">-Chris & the Core Team</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div class="section" id="se-0117-default-classes-to-be-non-subclassable-publicly" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14px;"></div></div></div></body></html>