Consider revising function argument defaulting

[jclark]

We should consider whether and, if so, how the design of function argument defaulting should be revised so as to

• align well with record field defaulting Allow record types to specify default values for fields #22
• fix useability limitations of current design Limit on function parameter defaults to compile-time constants #25, Positional parameters cannot have defaults #26

[jclark]

Scala (which shares our named argument syntax) has an interesting design, which I think we can borrow from:

https://docs.scala-lang.org/sips/completed/named-and-default-arguments.html
https://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#named-and-default-arguments

[jclark]

If we apply the Scala approach in the context of Ballerina, we would end up with something like this.

• Adding = expr in a parameter means only that the parameter has a default and thus does not need to be specified
• In a function call, a parameter can always be specified using its name.
• The caller of the function maps parameter names onto parameter positions using the function's type descriptor
• The name of a parameter does not affect the shape of the function and so does not affect function subtyping
• Parameter defaults are expressions (not necessarily compile-time constant expressions) that are evaluated for each function call.
• Expressions for parameter defaults can refer to earlier parameters and will get the actual value for this call not the default.
• Whether a particular parameter has a default is part of the shape of the function and affects subtyping, but the expression that computes the default is part of the function implementation, not part of the type.

[jclark]

Scala allows a named argument to occur before a positional argument in a function call, but requires that for such an argument the name and position must correspond (i.e. if argument number n has name x and occurs in a function call before a positional argument, then parameter number must also have name x). I am not sure if that is the right rule for us.

[jclark]

I wonder if we need a way to write the type of a function with a defaultable argument without specifying what the default is. Not very useful because you would not be able to call the function without specifying the defaultable argument, because you would not know what to default it to.

[jclark]

We should consider whether we want to allow foo(int x, int y = 0, int z) or whether we should require that once a parameter is given a default, all subsequent parameters should also be given a default.

[jclark]

For function call site, discussion suggests people prefer to have all arguments specified by position coming before all arguments specified by name.

[sameerajayasoma]

I think making all subsequent parameters to require a default after a parameter is given a default value will reduce the flexibility of this design. Yes, enforcing that all the positional arguments should come before named arguments is better IMO.

[jclark]

@sameerajayasoma The latter rule is about the call site. The former rule is about the declaration site. I don’t see the latter as an alternative to the former. Can you give an example of when you would need flexibility prohibited by the former rule?

The reason for the rule is to make it more obvious which parameter a positional argument corresponds to. Without this, people maybe unsure whether a positional argument specifies a defaultable parameter or a subsequent non-defaultable parameter.

[jclark]

Kotlin’s approach seems similar

https://kotlinlang.org/docs/reference/functions.html#named-arguments

[jclark]

We can distinguish two different approaches, depending on whether the defaultability of a parameter is part of the shape (ie affects subtyping).

The more straightforward approach is where defaultability is not part of the shape. The mapping of parameter names to positions and providing defaults for unspecified arguments is handled by the caller. The callee sees the ordered list of arguments ready to go. The typedesc conceptually provides both a parameter name-to-position map, and for each defaultable parameter a closure that computes the default value from the value of previous parameters (in a similar way to records).

It has the disadvantage that this does not work:

type F1 function(int x);
function foo(int x, int y = 0);
F1 f = foo;  // not allowed

One could have some built-in methods on the typedesc to generate wrappers automatically.

With this approach subtyping is straightforward, with the rest argument being the only complication.

[jclark]

Tentative conclusions after discussion between me and @sanjiva are:

• Defaultability (along with parameter name) is not part of the shape and does not affect subtyping, as described in previous comment.
• In a function call, after an argument is specified by name, all subsequent arguments must be specified by name
• In a function declaration, after a default is specified for a parameter, a default must be specified for all subsequent parameters