> Am 14.07.2016 um 16:46 schrieb Vladimir.S via swift-evolution > <swift-evolution@swift.org>: > > Just +100. One more wise decision from the core team. Thank you for all of > your work.
Indeed! Thank you! -Thorsten > >> On 14.07.2016 7:47, Chris Lattner via swift-evolution wrote: >> Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md >> >> 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. >> >> 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 "(a: Int) -> Int” to >> “(Int) -> Int”. However, there is also an implicit conversion from "(Int) >> -> Int” to “(b : Int) -> Int”. This means that the compiler currently >> allows converting from “(a: Int) -> Int” to “(b: Int) -> Int”, 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.) “(a : Int, b : Int) -> >> Void” to “(b : Int, a : Int) -> Void”, but this only triggers in specific >> cases. There are other more complex cases as well, e.g. when using >> generics "T<(a : Int)->Int>” cannot be considered compatible with "T<(b : >> Int)->Int>”. >> >> 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. >> >> ----8<---- >> >> 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: >> >> var op : (lhs : Int, rhs : Int) -> Int >> >> instead, it should be spelled as: >> >> var op : (_ lhs : Int, _ rhs : Int) -> Int >> >> 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. >> >> ----8<---- >> >> Here is a sketch of how that would work, in two steps: >> >> >> First, we extend declaration names for variables, properties, and >> parameters to allow *parameter names* as part of their declaration name. >> For example: >> >> var op(lhs:,rhs:) : (Int, Int) -> Int // variable or property. >> x = op(lhs: 1, rhs: 2) // use of the variable or property. >> >> // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”. >> func foo(opToUse op(lhs:,rhs:) : (Int, Int) -> Int) { >> x = op(lhs: 1, rhs: 2) // use of the parameter >> } >> foo(opToUse: +) // call of the function >> >> 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). >> >> >> 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: >> >> var op : (lhs: Int, rhs: Int) -> Int // Nice declaration syntax >> x = op(lhs: 1, rhs: 2) // Same as above >> >> // API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”. >> func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) { >> x = op(lhs: 1, rhs: 2) // Same as above. >> } >> foo(opToUse: +) // Same as above. >> >> >> 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. >> >> -Chris & the Core Team >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution