thoughts on having argument labels like in swift? ...

# language-proposals

[aarjav]

thoughts on having argument labels like in swift? https://docs.swift.org/swift-book/LanguageGuide/Functions.html#ID166
I can see it being helpful in dsl design but I haven't used them.

[ian.shaun.thomas]

unless I'm not understanding, we already have that right?

http://kotlinlang.org/docs/reference/functions.html#named-arguments

[Ruckus]

No, argument labels are basically a name alias, like in this example:

func greet(person: String, from hometown: String) -> String {
    return "Hello \(person)!  Glad you could visit from \(hometown)."
}
print(greet(person: "Bill", from: "Cupertino"))
// Prints "Hello Bill!  Glad you could visit from Cupertino."

Inside the function the variable is hometown, but outside the function the variable is from.
(Personally I don't like the idea at all, especially as the user is required to use them when present.)

[ian.shaun.thomas]

yeah that doesn't make sense to me ¯\_(ツ)_/¯

[Ruckus]

Kotlin's optionally named arguments are much better IMO

[ian.shaun.thomas]

agreed, use them all the time

[Ruckus]

The only real use case I've seen is when you have a function that takes a large number of fields of the same type like a bunch of flags, and you want to make extra sure the user is setting the appropriate flags, but that still feels a bit of overreach to me.

[ian.shaun.thomas]

that sounds like a case to just use a data class with defaults and then the kotlin naming approach allows for a simple sane way to set what you really need granted you could just do that via the function definition directly as well (sans the data class)

[Ruckus]

Exactly, functions with signatures like I described are more often then not a pretty strong code smell.

[aarjav]

What I like about it is the alias, not so much the required label. I think it could be implemented without requiring caller to use the argument labels if present. It could be just like named arguments except for the change that fun body would be using a different name. Weak example, but something like calls changing computeSum(a=1,b=2) to computeSum(of=1,and=2). There have been times where names for caller look good but awakward in fun body: = of + and vs a + b. other argument names are with, by, using, then. I guess its not very useful in most cases and could cause misunderstandings/bugs.

[ian.shaun.thomas]

that's an interesting example but how often do you think those scenarios crop up?

[aarjav]

I'm not really sure. My initial guess is not often. But that may just be because I haven't thought about using them since they're not available in the languages that I work with. Could look at how often swift users use that feature and if they actually found it helpful or not.

[Ruckus]

@aarjav I think in the Kotlin world, a and b would make more sense in your example, since there's nothing requiring argument order when using named arguments (there's nothing stopping the user from using computeSum(and = 2, of = 1), which makes a lot less sense than computeSum(b = 2, a = 1) where it's more immediately obvious I'm switching the order of the values).

If it really is a concern, you could always add some sort of inline fun computeSumFluent(of: Int, and: Int) = computeSum(of, and)

[gildor]

We had discussion about this a few months ago.
There are probably some use cases, especially if you want to use naming like in ObjC (where argument name is actually part of function name) that then moved to Swift.
But I still think this brings complexity with very few use cases