Re: [RFC] Named arguments

Hi John, On 05/05/2020 18:27, John Bafford wrote:

I very much do like the idea of named parameters, but I do not like the specific proposal in the linked RFC at all. I think that treating named parameters simply as syntactic sugar is not a good approach. If we're going to add named parameters, I think they should actually be significant in their own right. As such, please allow me to present an alternative. I would propose the following opt-in mechanism, which would work by treating the parameter names as*part of the function name*. Doing it this way I_think_ should allow for no backwards compatibility issues with existing code and would especially give library authors full control over the naming and presentation of their APIs.

I really like *some* of this proposal, but I think some of it is solving a different problem. You mention in a later e-mail that you've been heavily inspired by Swift; Swift in turn was inspired by Objective C, which was inspired by Smalltalk. This is an important piece of history, because Smalltalk doesn't actually have methods with named parameters; it has "keyword messages" whose "selectors" are things like "indexOf:startingAt:". Swift makes them look more familiar by keeping part of the name separate from what it calls "argument labels", so a method might be called "indexOf(_:startingAt:)" or "index(of:startingAt:)". Although at a glance these look like named parameters, and they solve some of the same problems, they're actually a fundamentally different concept. They have some nice features: * Method calls can be made to read like sentences * The external API of the function is kept separate from the internal implementation * You can skip over default arguments by omitting their labels * Overloading what looks like one method, by having different methods whose names start the same but have different "argument labels", may be appealing But there are some crucial limitations: * You can't call a method without using its labels; you'd need to have a separate method with a similar name and no labels * Similarly, it's up to the method's author to have versions with a mixture of unlabelled and labelled parameters, so a call like "create('hello', 42, locked: true)" is only possible if that specific variant is defined * You can't use the labels in the "wrong" order, you have to know the order they come in; so it doesn't solve the haystack/needle problem, except by creating extra function definitions * Similarly, methods with large numbers of arguments are still hard to use because you need to know both the name *and* the relative position of the arguments you're providing (imagine defining variants with every order of the 5 bit flags in the AMQP example in my earlier e-mail) It would be possible to take the "outside name is different from inside name" concept and apply it to named parameters proper. But the problems I would like to solve with named parameters wouldn't be solved by Swift/Smalltalk style functions. Regards, -- Rowan Tommins (né Collins) [IMSoP]