Include argument labels in identifiers

Evolution Pitches
, , ,
2

It's not only tacitly accepted, it is explicitly the plan of record:

To reformat the text for this forum, the relevant part is as follows:

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.

7 Likes