swift - 为什么我们可以在闭包的类型注释中使用 "internal argument labels"，而它们(看起来)永远无法访问？

Question

背景

这自然是合法的:

let closure: (Int, Int) -> () = { print($0 + $1) }
closure(1, 2) // 3

鉴于，自进化提案实现以来

• SE-0111: Remove type system significance of function argument labels

在 Swift 3 中，以下内容是不合法的:

let closure: (a: Int, b: Int) -> () = { /* ... */ }

Error: function types may not have argument label a, use _ instead.

这是预期的，正如 SE-0111 中的引述:

Function types may only be defined in terms of the types of the formal parameters and the return value.

但奇怪的是(如上面的错误消息所提示)，这是合法的:

let closure: (_ a: Int, _ b: Int) -> () = { print($0 + $1) }
closure(1, 2) // 3

但是，据我所知，我们永远不能使用上面的 a 和 b(它们甚至不应该被允许，因为它们是不是参数类型的一部分？)。

问题

• 上面最后的代码片段是否合法？我们可以使用或访问“内部参数标签”a 和 b(鉴于引用，我们不应该......)，或者这可能是对SE-0111 的实现？

Answer 1

您观察到的是为闭包类型定义“纯装饰性”参数标签的能力。这被接受为 SE-0111 的一部分，如所述 in the rationale :

In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section).

这些装饰性参数标签的语法在要求参数标签为 _ 的提议后发生了变化，以明确表示装饰性标签未在调用站点使用。这在 an additional commentary 中有详细说明。 :

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

尽管实际上，这实际上使装饰性标签变得毫无用处，因为它们不会出现在调用站点，甚至不会出现在自动完成中——仅出现在实际声明本身。因此，他们 self 记录的意图有些迷失。

Swift 团队意识到了这个缺点，并将寻求在 Swift 3 之后进行纯粹的附加更改以纠正这种情况。

这是他们提出的草图(同样在 the additional commentary 中):

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.

这个提议的解决方案非常好地允许在调用站点使用标签，允许自记录参数标签，同时不会使类型系统复杂化。此外(在大多数情况下)它允许在闭包的参数类型旁边编写标签的表达语法——我们习惯于在 Swift 3 之前这样做。