# \[Proposal draft #2\] Naming Functions with Argument Labels **URL:** \ **Category:** Discussion\ **Created:** [January 11, 2016, 7:03pm UTC](https://forums.swift.org/t/proposal-draft-2-naming-functions-with-argument-labels/1018 "2016-01-11T19:03:27Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![hartbit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hartbit/32/738_2.png) [@hartbit](https://forums.swift.org/u/hartbit)\ **Post date:** [January 11, 2016, 10:32pm UTC](https://forums.swift.org/t/proposal-draft-2-naming-functions-with-argument-labels/1018/21 "2016-01-11T22:32:29Z")
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 \ wrote: > > > > > On Jan 11, 2016, at 1:53 PM, Tino Heth \<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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Andrew](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrew/32/949_2.png) [@Andrew](https://forums.swift.org/u/Andrew)\ **Post date:** [January 11, 2016, 11:14pm UTC](https://forums.swift.org/t/proposal-draft-2-naming-functions-with-argument-labels/1018/22 "2016-01-11T23:14:11Z")
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](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [January 12, 2016, 7:43am UTC](https://forums.swift.org/t/proposal-draft-2-naming-functions-with-argument-labels/1018/23 "2016-01-12T07:43:49Z")
> > > 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 \ wrote: > > > -- > > Brent Royal-Gordon > > Architechies ---
**Author:** ![Brent\_Royal-Gordon](https://avatars.discourse-cdn.com/v4/letter/b/53a042/32.png) [@Brent\_Royal-Gordon](https://forums.swift.org/u/Brent_Royal-Gordon)\ **Post date:** [January 12, 2016, 7:52am UTC](https://forums.swift.org/t/proposal-draft-2-naming-functions-with-argument-labels/1018/24 "2016-01-12T07:52:56Z")
> > > 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 ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [January 12, 2016, 6:20pm UTC](https://forums.swift.org/t/proposal-draft-2-naming-functions-with-argument-labels/1018/25 "2016-01-12T18:20:23Z")
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 \ 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? [Previous page](https://forums.swift.org/t/proposal-draft-2-naming-functions-with-argument-labels/1018.md?page=1)