[Proposal draft #2] Naming Functions with Argument Labels

Evolution Discussion
21

I really like this proposal and looking forward to the objc selector binding.

···

On 11 Jan 2016, at 22:54, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 11, 2016, at 1:53 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:

We discussed this a looooong while back and decided that we wanted the ‘_’ to emphasize that there is an argument there. The difference between “foo(:bar:)” and “foo(bar:)” is barely visible.

That is true, but I think it is very uncommon to have such a set of methods — and afaics, it would violate the guidelines for method names.

But speaking of additional characters that might be useful:
What about the parameter types? When they are needed to identify the exact function, it would be nice if they could be included as well.

foo(bar:(Int))
(that's why I wanted to avoid the parenthesis in the first place…)

It’s grammatically ambiguous if you don’t have the “:)” at the end and, IMO, it’s not important enough to have special syntax for this: one can still coerce to a specific function type.

  - Doug

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

22

I'm for this proposal, but not for the syntax. If this proposal is mutually
exclusive with Bartlomiej's then I am -1 on Douglas'.

I was initially against _, but it is necessary to disambiguate cases like
this:

    naming a function: MyStruct.test(_),
    calling a function: MyStruct.test()

However I think that the syntax is closer to something we'd expect in
Objective-C than in Swift. I wonder if it would make sense to someone
unfamiliar with Objective-C.

Consider:
    struct MyStruct {
        static func test(a: Int, _ b: Int, _ c: Int) {}
    }
    MyStruct.test(1,2,3) // calling the function
    MyStruct.test(_:_:_) // naming the function

In this case I would expect to name the function like one of these:
    MyStruct.test(_,_,_)
    MyStruct.test(,,)

I would +1 this proposal if the syntax was like this:
    let fn1 = someView.insertSubview(_,aboveSubview:_)
    let fn = someView.insertSubview(_,at:_)

Instead of:
    let fn1 = someView.insertSubview(_:aboveSubview:)
    let fn = someView.insertSubview(_:at:)

I think it's more consistent with other *Swift* function syntax.
Additionally it is compatible with the syntax Bartlomiej proposes (see fn1).

Perhaps you can make the _ optional (for disambiguation), but commas should
be consistent with declaration/calling syntax.

We discussed this a looooong while back and decided that we wanted the

‘_’ to emphasize that there is an argument there. The difference between
“foo(:bar:)” and “foo(bar:)” is barely visible.

That is true, but I think it is very uncommon to have such a set of

methods — and afaics, it would violate the guidelines for method names.

But speaking of additional characters that might be useful:
What about the parameter types? When they are needed to identify the

exact function, it would be nice if they could be included as well.

foo(bar:(Int))
(that's why I wanted to avoid the parenthesis in the first place…)

It’s grammatically ambiguous if you don’t have the “:)” at the end and,

IMO, it’s not important enough to have special syntax for this: one can
still coerce to a specific function type.

···

On Tue, Jan 12, 2016 at 8:54 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 11, 2016, at 1:53 PM, Tino Heth <2th@gmx.de> wrote:

- Doug

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

23

foo(bar:(Int))
(that's why I wanted to avoid the parenthesis in the first place…)

It’s grammatically ambiguous if you don’t have the “:)” at the end

Is it? It's not legal to pass a type name—`foo(bar: Int)` is not legal code; you have to say `foo(bar: Int.self)`.

"Grammatically" is key here: the parser doesn't know a type name from a variable name.

···

Sent from my iPhone
On Jan 11, 2016, at 11:22 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

--
Brent Royal-Gordon
Architechies

24

It’s grammatically ambiguous if you don’t have the “:)” at the end

Is it? It's not legal to pass a type name—`foo(bar: Int)` is not legal code; you have to say `foo(bar: Int.self)`.

"Grammatically" is key here: the parser doesn't know a type name from a variable name.

Okay, but is it important to distinguish the two grammatically? A function call and a function reference are both expressions and can (types aside) both be used in the same places, right?

···

--
Brent Royal-Gordon
Architechies

25

IMO, it’s important to distinguish them grammatically. Yes, one could potentially make the type checker sort it out, but it adds significant complexity to the feature and the compiler, for the benefit of a small corner case that could be handled via type context already. Moreover, it means that we wouldn’t be able to take this currently-invalid code

  foo(bar: Int)

and correct it to

  foo(bar: Int.self)

which is almost surely what the user meant (the “.self” rule is a tricky one to remember).

  - Doug

···

On Jan 11, 2016, at 11:52 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

It’s grammatically ambiguous if you don’t have the “:)” at the end

Is it? It's not legal to pass a type name—`foo(bar: Int)` is not legal code; you have to say `foo(bar: Int.self)`.

"Grammatically" is key here: the parser doesn't know a type name from a variable name.

Okay, but is it important to distinguish the two grammatically? A function call and a function reference are both expressions and can (types aside) both be used in the same places, right?