SE-0111 related question

Development Compiler
1

Sorry for mentioning this issue again, as it seems to have been already
much discussed, but i've had the unfortunate experience of dealing with the
consequences of this proposal in my code since xcode beta 6, which i really
can't get my head around.

Could someone explain what is the rational behind the choice of having
parameter names prohibited for closures but compulsory for functions ?

As a software developper (and not a language expert), I would have hoped to
get functions behave as close to closures as possible.

aka :

func myAdd(a : Int, b: Int) -> Int
myAdd(a: 1 , b :2 ) -- OK

vs

let myAdd = (_ a: Int, _ b: Int) -> Int
myAdd (a:1, b: 2) -- not ok still ?

After having read the argument that "parameter names are part of the
function names, and not its type", i'm convinced that the whole proposal
makes sense. However i can't get my head around that specific line of the
proposal :
"If the invocation refers to a value, property, or variable of function
type, the argument labels do not need to be supplied. *It will be an error
to supply argument labels in this situation*."

Why make it an error in case of closures ? If we agree that parameter are
part of the name, then it should behave just like a name. Specifying names
shouldn't matter more than the name of the variable storing the closure. It
seems to me, humbly, that the fact that part of the name is split and
written closer to the parameters could be considered just as syntactic
sugar.

Another hint that something's wrong : the proposal still lets the
possibility to specify names in type declarations for documentation
purpose, using "_" . But then why not let us specify those names at call
site too ?
callback( nil, nil, nil, request) isn't really pleasant to read compared to
callback(data:nil, error:nil, info:nil, request: request)

Sorry again if i'm reopening a settled discussion, but once again me and
the people i'm working with all had trouble understanding the rational
behind the changes induced in our code.

Benjamin

2

Sorry for mentioning this issue again, as it seems to have been already much discussed, but i've had the unfortunate experience of dealing with the consequences of this proposal in my code since xcode beta 6, which i really can't get my head around.

Could someone explain what is the rational behind the choice of having parameter names prohibited for closures but compulsory for functions ?

As a software developper (and not a language expert), I would have hoped to get functions behave as close to closures as possible.

aka :

func myAdd(a : Int, b: Int) -> Int
myAdd(a: 1 , b :2 ) -- OK

vs

let myAdd = (_ a: Int, _ b: Int) -> Int
myAdd (a:1, b: 2) -- not ok still ?

This is a topic for swift-evolution; adding swift-evolution, and BCC’ing swift-dev.

After having read the argument that "parameter names are part of the function names, and not its type", i'm convinced that the whole proposal makes sense. However i can't get my head around that specific line of the proposal :
"If the invocation refers to a value, property, or variable of function type, the argument labels do not need to be supplied. It will be an error to supply argument labels in this situation."

Why make it an error in case of closures ?

A closure is an expression that creates an anonymous function, hence there is no place to put the argument labels.

If we agree that parameter are part of the name, then it should behave just like a name. Specifying names shouldn't matter more than the name of the variable storing the closure. It seems to me, humbly, that the fact that part of the name is split and written closer to the parameters could be considered just as syntactic sugar.

We could invent a language extension there. The point of requiring the underscores in:

  let myAdd: (_ a: Int, _ b: Int) -> Int

Is to allow for some future evolution here. IIRC, it was discussed in the review thread, that we could imagine ‘let’s with compound names, e.g.,

  let myAdd(a:b:): (Int, Int) -> Int

Or perhaps allow syntactic sugar such as

  let myAdd: (a: Int, b: Int) -> Int

To be the same thing. Again, this is future language extensions.

Another hint that something's wrong : the proposal still lets the possibility to specify names in type declarations for documentation purpose, using "_" . But then why not let us specify those names at call site too ?

Because they are parameter names, not argument labels. If you declare a function with parameter names but not argument labels:

  func f(_ a: Int) { }

You *cannot* specify argument labels at the call site:

  f(a: 1) // error: first argument is unlabeled

callback( nil, nil, nil, request) isn't really pleasant to read compared to callback(data:nil, error:nil, info:nil, request: request)

This was a known issue with the Swift 3 change, and there are (known) possible future language directions to bring back some of this. We focused on fixing the type system oddities first in Swift 3 (that’s the breaking part) and can consider improvements in the future.

  - Doug

···

On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev <swift-dev@swift.org> wrote:

3

They don’t have ABI impact, so they’d be the in “stage 2” bucket for Swift 4.

  - Doug

···

On Aug 18, 2016, at 11:17 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Sorry for mentioning this issue again, as it seems to have been already much discussed, but i've had the unfortunate experience of dealing with the consequences of this proposal in my code since xcode beta 6, which i really can't get my head around.

Could someone explain what is the rational behind the choice of having parameter names prohibited for closures but compulsory for functions ?

As a software developper (and not a language expert), I would have hoped to get functions behave as close to closures as possible.

aka :

func myAdd(a : Int, b: Int) -> Int
myAdd(a: 1 , b :2 ) -- OK

vs

let myAdd = (_ a: Int, _ b: Int) -> Int
myAdd (a:1, b: 2) -- not ok still ?

This is a topic for swift-evolution; adding swift-evolution, and BCC’ing swift-dev.

After having read the argument that "parameter names are part of the function names, and not its type", i'm convinced that the whole proposal makes sense. However i can't get my head around that specific line of the proposal :
"If the invocation refers to a value, property, or variable of function type, the argument labels do not need to be supplied. It will be an error to supply argument labels in this situation."

Why make it an error in case of closures ?

A closure is an expression that creates an anonymous function, hence there is no place to put the argument labels.

If we agree that parameter are part of the name, then it should behave just like a name. Specifying names shouldn't matter more than the name of the variable storing the closure. It seems to me, humbly, that the fact that part of the name is split and written closer to the parameters could be considered just as syntactic sugar.

We could invent a language extension there. The point of requiring the underscores in:

  let myAdd: (_ a: Int, _ b: Int) -> Int

Is to allow for some future evolution here. IIRC, it was discussed in the review thread, that we could imagine ‘let’s with compound names, e.g.,

  let myAdd(a:b:): (Int, Int) -> Int

Or perhaps allow syntactic sugar such as

  let myAdd: (a: Int, b: Int) -> Int

To be the same thing. Again, this is future language extensions.

Another hint that something's wrong : the proposal still lets the possibility to specify names in type declarations for documentation purpose, using "_" . But then why not let us specify those names at call site too ?

Because they are parameter names, not argument labels. If you declare a function with parameter names but not argument labels:

  func f(_ a: Int) { }

You *cannot* specify argument labels at the call site:

  f(a: 1) // error: first argument is unlabeled

callback( nil, nil, nil, request) isn't really pleasant to read compared to callback(data:nil, error:nil, info:nil, request: request)

This was a known issue with the Swift 3 change, and there are (known) possible future language directions to bring back some of this. We focused on fixing the type system oddities first in Swift 3 (that’s the breaking part) and can consider improvements in the future.

Would the future directions given in SE-0111 be appropriate for consideration in the current phase of Swift 4 evolution, or would they be irrelevant to the ABI?

4

Right, FWIW, these ideas were discussed here, which is linked off the SE-0111 proposal.
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

-Chris

···

On Aug 18, 2016, at 11:10 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

If we agree that parameter are part of the name, then it should behave just like a name. Specifying names shouldn't matter more than the name of the variable storing the closure. It seems to me, humbly, that the fact that part of the name is split and written closer to the parameters could be considered just as syntactic sugar.

We could invent a language extension there. The point of requiring the underscores in:

  let myAdd: (_ a: Int, _ b: Int) -> Int

Is to allow for some future evolution here.

5

Sorry for mentioning this issue again, as it seems to have been already
much discussed, but i've had the unfortunate experience of dealing with the
consequences of this proposal in my code since xcode beta 6, which i really
can't get my head around.

Could someone explain what is the rational behind the choice of having
parameter names prohibited for closures but compulsory for functions ?

As a software developper (and not a language expert), I would have hoped
to get functions behave as close to closures as possible.

aka :

func myAdd(a : Int, b: Int) -> Int
myAdd(a: 1 , b :2 ) -- OK

vs

let myAdd = (_ a: Int, _ b: Int) -> Int
myAdd (a:1, b: 2) -- not ok still ?

This is a topic for swift-evolution; adding swift-evolution, and BCC’ing
swift-dev.

After having read the argument that "parameter names are part of the
function names, and not its type", i'm convinced that the whole proposal
makes sense. However i can't get my head around that specific line of the
proposal :
"If the invocation refers to a value, property, or variable of function
type, the argument labels do not need to be supplied. *It will be an
error to supply argument labels in this situation*."

Why make it an error in case of closures ?

A closure is an expression that creates an anonymous function, hence there
is no place to put the argument labels.

If we agree that parameter are part of the name, then it should behave
just like a name. Specifying names shouldn't matter more than the name of
the variable storing the closure. It seems to me, humbly, that the fact
that part of the name is split and written closer to the parameters could
be considered just as syntactic sugar.

We could invent a language extension there. The point of requiring the
underscores in:

let myAdd: (_ a: Int, _ b: Int) -> Int

Is to allow for some future evolution here. IIRC, it was discussed in the
review thread, that we could imagine ‘let’s with compound names, e.g.,

let myAdd(a:b:): (Int, Int) -> Int

Or perhaps allow syntactic sugar such as

let myAdd: (a: Int, b: Int) -> Int

To be the same thing. Again, this is future language extensions.

Another hint that something's wrong : the proposal still lets the
possibility to specify names in type declarations for documentation
purpose, using "_" . But then why not let us specify those names at call
site too ?

Because they are parameter names, not argument labels. If you declare a
function with parameter names but not argument labels:

func f(_ a: Int) { }

You *cannot* specify argument labels at the call site:

f(a: 1) // error: first argument is unlabeled

callback( nil, nil, nil, request) isn't really pleasant to read compared
to callback(data:nil, error:nil, info:nil, request: request)

This was a known issue with the Swift 3 change, and there are (known)
possible future language directions to bring back some of this. We focused
on fixing the type system oddities first in Swift 3 (that’s the breaking
part) and can consider improvements in the future.

Would the future directions given in SE-0111 be appropriate for
consideration in the current phase of Swift 4 evolution, or would they be
irrelevant to the ABI?

···

On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev <swift-dev@swift.org> > wrote:

- Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution