Make All Parameters Named and Required by Default

[fniemann]

The current pattern of having unnamed-positional-required and named-optional parameters is not very flexible and has a few shortcomings.

Other languages such as Python or C# allow all parameters to be named and optional. There are just rules around when they become optional or how to use them as positional or named parameters.

Here are some ideas on how this could look like:

• All parameters are required by default
• Parameters can be made optional by providing a default value
• Optional parameters come last (not sure if this has to be a requirement, but seems sensible)
• All parameters can be used as positional parameters, but have to be in the order they appear in the method declaration
• All parameters can be used as named parameters
• Positional parameters can also be used with their name for documentation purposes (not sure if this is possible or if named parameters have to come last, but seems like a nice feature to be able to use the name for documentation when passing in bools, numbers or string literals)

[lrhn]

We also have unnamed-positional-optional parameters now. A major pain point is that you can't combine optional positional parameters and optional named parameters in the same function. Making all parameters passable as named will obviously alleviate that.

We definitely want to allow named parameters before positional parameters. That allows you to write a closure as the last parameter, whether it's named or not.

So, to include that, and specify what happens when positional and named arguments are used in the same call, I think this can be written as:

Dart supports dynamic calls, so it must be possible for a method invocation to match arguments to parameters in a consistent way without knowing the signature of the function at compile-time.
We also need to consider interaction with noSuchMethod.

So, lets try to summarize:

• All parameters have a name. No two parameters on the same function have the same name.
• Parameters are either required or optional.
• A parameter is optional if it has a default value (parameter-decl = defaultValue).
• All optional parameters must occur after all non-optional parameters in a function or function-type declaration.
• Arguments are either named or positional.
• Named arguments are prefixed by name:.
• Named arguments can occur anywhere in an invocation, both before, after and between positional arguments.
• Arguments are matched to parameters by first matching all named arguments with parameter names, and then matching all positional arguments with the remaining parameters in declaration order.
• An invocation is invalid if it has a named argument that has no corresponding named parameter, or if it has a require parameter with no positional argument that matches it.
• A valid invocation binds each parameter to the matched argument, and all remaining (necessarily optional) parameters to their default value.
• A noSuchMethod invocation is unchanged from now, it still receives both positional and named arguments. Similarly, Function.apply takes both positional and named arguments.

This also requires changes to the (function) type system:

• Function types include names of parameters.
• A function type F2 is a subtype of a function type F1 iff
  • F2 has at least as many parameters as F1
  • F2 has at most the same number of required parameters as F1
  • All the parameter names of F1 are also the initial parameter names of F2, in the same order.
  • All the usual type constraints.

That is, a function subtype can add new optional parameters and it can make the last required parameters optional. It cannot change the name of any parameter of the supertype function since there might be a call of that function that passes that particular parameter with a named argument.

As previously mentioned, this is actually very restrictive when dealing with first-class functions.
The Iterable.forEach method has signature void forEach(void action(E element)). If all arguments can be named, then it isn't possible to call list.forEach(print) because print has signature void print(Object object), and the name doesn't match.
That means that such a type system is basically a no-go for a language with first-class functions.

One solution could be to only allow named arguments for required parameters on methods, not on functions.
A method is more than just a function type. It has a structure that is inherited through the class hierarchy, and requiring subclasses to have the same name is not a big restriction.
If you tear off a method, it becomes a plain function, and you can call its with named arguments only for optional parameters. That ensures that you can pass a function as an argument without knowing how it will be called, because the required parameters cannot be named.

That's complicated and potentially confusing and it suggests not allowing required parameters to be passed using their name at all.
Also, a class implementing both List and Queue must have an add method that implements both List.add and Queue.add. Luckily we named both arguments value, so it's possible, but it's extremely easy to imagine a case where that wasn't the case. We also named the addAll argument iterable in both cases, but we should really have named them values or elements, and if it actually mattered, we might have done so for one of them.

All in all, I think making all parameters callable by name is very costly in the programs it prevents, even if it's only on methods (extra complexity cost due to being an exception, and still being a complication that users have to work around).

Again, Dart not having overloading prevents the resolution that other languages can use, they allow distinguishing methods on the signature, including name, and implementing both methods.

So, if we are back to only allowing optional parameters to be used by their name, then we are just merging positional and named arguments. That was what Dart originally had.

You could say that Dart's optional parameters is a way to simulate overriding. That's why it's useful to allow foo(x, [y]), it allows you to implement both a one- and a two-argument method without having to worry about the parameter names. It's really a declaration-site thing, functions that expect functions as arguments almost never expect a type with optional parameters - they know exactly how many arguments will be present and have no problem passing a null if one parameter isn't needed. You can pass a Function(int, [int]) to something expecting Function(int) and Function(int, int), but there won't be anything expecting exactly Function(int, [int]). What happens instead, e.g., in Future.catchError, is that we allow both Function(int) and Function(int, int) as a service to the user.

I'm not sure making all optional parameters named (but passable by position as well) will actually match what you need to write useful programs in Dart, because it moves it further away from actually allowing multiple signatures on the same function - by making both names and positions significant at the same time.

[lrhn]

We are not planning on changing the parameter rules in a non-backwards compatible way at this point.
For the reasons given above, this particular change is not tractable for Dart.

[xVemu]

@lrhn Any changes after 5 years?