3 ms·

I’m very disappointed when I see new languages (cough Rust) not even consider named arguments. The added readability at call sites just seems like a no-brainer

I’m very disappointed when I see new languages (cough Rust) not even consider named arguments. The added readability at call sites just seems like a no-brainer to me.

inertiatic 7y ago
It should be easy to implement on a modern IDE, right? I think intellij exposes a setting for example.
simias 7y ago
The only counter-argument I've heard was that it has the consequence of making the argument name part of the API (i.e. changing the name would be a breaking change, so all parameter names of exported functions "leak" into the public interface). That always seemed like a very minor drawback to me, I too would appreciate to have named arguments in Rust.
- Matt3o12_ 7y ago
  It seems more like a feature to me. Sometimes parameters change slightly and you will never notice it until you re-read the docs. So if the change is explicit I can go look at it during compile time and not be surprised by it during runtime. Of course there are occasions where the name is unfortunate (typo, ambiguous name or incorrect term) but the docs could mention it and it would not be the end of the world.
  - simias 7y ago
    I agree, although I haven't done enough work with languages using named parameters to really judge how inconvenient they can become in practice. It seems like most naming issues could be alleviated by allowing the developer to provide aliases, this way you can change the preferred parameter name while still keeping the old one around for backward compatibility.
- mpweiher 7y ago
  Hmm...the argument names seen in the method don't leak in Smalltalk. They do in Swift's attempt at a keyword syntax.
- hnick 7y ago
  I think it's better than the alternative too. You always have some concept of the API leak into the consumer. You either remember explicit names, or remember their positional pseudo-names 'first', 'second', 'third' etc. Unnamed arguments bring up more issues such as ordering consistency (see: PHP's many notorious cases), deprecation leaving 'holes' in argument lists, etc. In Perl and many other languages we just provide a hash (aka dict) of key/value pairs. This lets the functions decide how to handle breaking changes which involves some annoying boilerplate but overall works fairly well. It's nicer with proper language support though.
edflsafoiewq 7y ago
There are some difficulties to solve around how higher-order functions should work.
estebank 7y ago
The pattern in rust is to use enums and structs instead. Design patterns are always needed when the language doesn't support a given construct but once it's usefulness is established language designers incorporate to (the same or other) language. The problem with named parameters as seen in Python is that then the name of the parameters become part of your APIs contract, making changes to your API harder. This has been remediated with patterns in Python 2 and explicit design in Python 3 by incorporating named only parameters so that you can't call them with both positional or named args.
- madhadron 7y ago
  This isn't quite what the OP is referring to. In Smalltalk, all arguments are named all the time, including positional arguments. Object methods aren't named separately from their parameters. They are only their set of named arguments, i.e., So say I have a BankAccount class. In Python I would write a method to transfer to another account def transfer(this, to, amount): ... and invoke it as account.transfer(other_account, 500) In Smalltalk I would write transferTo: account amount: n [ ... ] and invoke it as account transferTo: other_account amount: 500. So it's not quite named arguments. It's that there isn't a distinction between name of function, argument name, and positional parameters. It just doesn't map to the function notation typical from mathematics.
- coldtea 7y ago
  >The problem with named parameters as seen in Python is that then the name of the parameters become part of your APIs contract, making changes to your API harder. Huh? How are APIs with mere positional parameters easier to change and more transparent to the callers when changed?

I’m very disappointed when I see new languages (cough Rust) not even consider named arguments. The added readability at call sites just seems like a no-brainer to me.

inertiatic 7y ago

It should be easy to implement on a modern IDE, right? I think intellij exposes a setting for example.

simias 7y ago

The only counter-argument I've heard was that it has the consequence of making the argument name part of the API (i.e. changing the name would be a breaking change, so all parameter names of exported functions "leak" into the public interface). That always seemed like a very minor drawback to me, I too would appreciate to have named arguments in Rust.

Matt3o12_ 7y ago
It seems more like a feature to me. Sometimes parameters change slightly and you will never notice it until you re-read the docs. So if the change is explicit I can go look at it during compile time and not be surprised by it during runtime. Of course there are occasions where the name is unfortunate (typo, ambiguous name or incorrect term) but the docs could mention it and it would not be the end of the world.
- simias 7y ago
  I agree, although I haven't done enough work with languages using named parameters to really judge how inconvenient they can become in practice. It seems like most naming issues could be alleviated by allowing the developer to provide aliases, this way you can change the preferred parameter name while still keeping the old one around for backward compatibility.
mpweiher 7y ago
Hmm...the argument names seen in the method don't leak in Smalltalk. They do in Swift's attempt at a keyword syntax.
hnick 7y ago
I think it's better than the alternative too. You always have some concept of the API leak into the consumer. You either remember explicit names, or remember their positional pseudo-names 'first', 'second', 'third' etc. Unnamed arguments bring up more issues such as ordering consistency (see: PHP's many notorious cases), deprecation leaving 'holes' in argument lists, etc. In Perl and many other languages we just provide a hash (aka dict) of key/value pairs. This lets the functions decide how to handle breaking changes which involves some annoying boilerplate but overall works fairly well. It's nicer with proper language support though.

edflsafoiewq 7y ago

There are some difficulties to solve around how higher-order functions should work.

estebank 7y ago

The pattern in rust is to use enums and structs instead. Design patterns are always needed when the language doesn't support a given construct but once it's usefulness is established language designers incorporate to (the same or other) language. The problem with named parameters as seen in Python is that then the name of the parameters become part of your APIs contract, making changes to your API harder. This has been remediated with patterns in Python 2 and explicit design in Python 3 by incorporating named only parameters so that you can't call them with both positional or named args.

madhadron 7y ago
This isn't quite what the OP is referring to. In Smalltalk, all arguments are named all the time, including positional arguments. Object methods aren't named separately from their parameters. They are only their set of named arguments, i.e., So say I have a BankAccount class. In Python I would write a method to transfer to another account def transfer(this, to, amount): ... and invoke it as account.transfer(other_account, 500) In Smalltalk I would write transferTo: account amount: n [ ... ] and invoke it as account transferTo: other_account amount: 500. So it's not quite named arguments. It's that there isn't a distinction between name of function, argument name, and positional parameters. It just doesn't map to the function notation typical from mathematics.
coldtea 7y ago
>The problem with named parameters as seen in Python is that then the name of the parameters become part of your APIs contract, making changes to your API harder. Huh? How are APIs with mere positional parameters easier to change and more transparent to the callers when changed?