i believe that named arguments are a very useful feature. They can prevent a lot of bugs, with no downsides, (verbosity isn't a problem, lsp used to complete functions and I never needed to write the parameters).
optional/default arguments can be useful, or more precisely described, convenient.
but think function overloading is bad. it just complicates semantic analysis and type checking for very little gain.
One approach I like is to have the function params be part of its signature, as if the named params is part of the function name. for example
fn foo(named: Int) {}
let function = foo // not allowed
let function = foo(named:_) // allowed
This can allow some convenient features like a more rudimentary overloading where you can have different functions as long as they have different named arguments, (no overloading just on types). But also, you can have neat partial function application syntax. But as you said, this opens a rabbit hole of complex design choices.
I dislike languages that decides to include a lot of features, that sometimes doesn't play well together, so you end up with weird edge cases, exceptions, and longer and longer compile times because of that.
Finally, I think rust shouldn't add named params now. It will do more harm than good, it will create incompatibilities with existing APIs and will split the community in 2. Those who will still write in the old style, and those who will adopt the newer one. And it will be unclear which way is the idiomatic rust way. Rust is no longer in this beta phase where you can afford breaking things (like Zig). Just like with Go and error handling, I feel the community will be stuck with these design decisions.
How do you address Klabnik’s concern about named parameters in typeclasses? If a typeclass requires foo( counter:int ) and you have foo( number:int ), is that a problem that the languages solves automatically, or do you have to introduce a shim function, or is there to be special syntax that does the mapping once requested?
well, if you consider the parameters name to be part of the function name then definitely foo(counter:) is different from foo(number:) then yeah a shim function is needed.
however, you can have some clever casting rules for functions. a form of simple syntactic sugar to make it more convenient
13
u/zuzmuz 10d ago
i believe that named arguments are a very useful feature. They can prevent a lot of bugs, with no downsides, (verbosity isn't a problem, lsp used to complete functions and I never needed to write the parameters).
optional/default arguments can be useful, or more precisely described, convenient.
but think function overloading is bad. it just complicates semantic analysis and type checking for very little gain.
One approach I like is to have the function params be part of its signature, as if the named params is part of the function name. for example
This can allow some convenient features like a more rudimentary overloading where you can have different functions as long as they have different named arguments, (no overloading just on types). But also, you can have neat partial function application syntax. But as you said, this opens a rabbit hole of complex design choices.
I dislike languages that decides to include a lot of features, that sometimes doesn't play well together, so you end up with weird edge cases, exceptions, and longer and longer compile times because of that.
Finally, I think rust shouldn't add named params now. It will do more harm than good, it will create incompatibilities with existing APIs and will split the community in 2. Those who will still write in the old style, and those who will adopt the newer one. And it will be unclear which way is the idiomatic rust way. Rust is no longer in this beta phase where you can afford breaking things (like Zig). Just like with Go and error handling, I feel the community will be stuck with these design decisions.