Call-by-name functions

[SnirkImmington]

I'm writing a regression in the typeck branch, to go back to call-by-argument functions. The current master (as of 8a20dc5) requires that all parameters to functions be named, and allows variables to be used as the names:

fn foo(x, y)
    if x == 0 => 1 else foo(x: x -1, y)

The exception for this is single argument functions - for them, the naming rules are ignored.

Call by argument name

Okay, here's how it should work:

When you're writing a function, you can ask for named parameters after a certain index with the keyword named:

// exp(5, pow: 2)
fn exp(base: int, named pow: int) -> int

// stats(median: x, mode: mode)
fn stats(named median: int, mode: int) -> int

The compiler should also emit a warning if you have two or more arguments of the same type which are not named.

What about when you're calling a function? We enforce call by parameter name. All parameters after named must be call-by-name in callers.
This is done by the syntax paramName: <expr>.

If we allow callers to specify names whenever they want, however, the caller cannot rename parameters without breaking API compatibility. This may be a worthwhile tradeoff, however.

Motivations

As with other languages with call-by-name functions (especially statically typed ones, like C#), our motivation is to make code more readable.

I can imagine guidelines for named arguments reading as:

Use named parameters for parameters of a function that

• are of the same or similar type, cannot be reordered, and for which a standard order is not obvious
• values not identifiable by name (such as flags which use a boolean instead of named enum)

[Timidger]

I think you should reverse it. By default fields are explicitly named at the call site and to opt out of that you use a keyword in the function definition (e.g implicit).

Except for simple functions (which will be few per module and mostly concentrated on the std and very generic libraries (e.g. standard collections, math, random, etc.) you almost always want explicit names at call sites.

I would argue you don't want to have the special case one argument rule because it's simple enough to add the implicit keyword.

And on the other side you don't want to have an explicit keyword because it will get annoying to type out and convince the user to not write it because the user is a programmer and a programmer is lazy.

Finally, it's better for APIs. Explicit to implicit is not a breaking change (because you can still specify the name). Implicit to explicit IS a breaking change. So removing the keyword now makes it a breaking change instead of adding it.