Re: [RFC] Named arguments

On Tue, May 5, 2020 at 8:22 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > Anyway. Your point that named arguments expand the API surface has been > acknowledged. I don't think this issue is really avoidable, it's a rather > fundamental trade-off of named parameters. I do think you're a bit quick in > jumping to conclusions. It's not like this problem doesn't exist in > (nearly) every language supporting named arguments. > > There are some things we can do to mitigate this though. One that we > recently discussed in chat is to allow methods to change parameters during > inheritance, and allow named arguments to refer to the parameter names of > the parent method as well. Renaming parameters in a way that causes > conflicts (same parameter name at different position) would cause an LSP > error. I'm not entirely convinced this is the best approach yet, but this > does address some concerns (including the "interface extraction" concern > you mention on reddit). > > Another is to allow specifying the public parameter name and the private > parameter variable name separately, as is possible in Swift. This would > allow changing "parameter" names arbitrarily, without breaking the public > API. This would be a pretty direct counter to your concern, but I'm not > really sure that your concern is important enough to warrant the additional > weight in language complexity. I've never used Swift myself, so maybe this > is actually awesome and I just don't know it. > > Regards, > Nikita > Hi, If I understand this correctly, something like this could be done? ``` // current version, argument name = "firstArgument" function example(string $firstArgument) {} // name changes, bc can be kept, argument name = "firstArgument" and "argument" function example(string firstArgument: $argument) {} ``` This would make it possible to keep backwards compatibility, and perhaps even trigger a notice when called with the old name? Regards, Lynn