TE131 — named-argument call requires a locally-declared function signature

Why this fires¶

A call with at least one named argument (f(name: value)) could not be safely reordered to the callee's declared parameter order. Zolo binds named arguments by name — the compiler reorders them to match the declaration before the call runs — but it refuses to do so, and reports TE131, when:

The label doesn't match any declared parameter name (a "did you mean?" suggestion is attached when a close match exists).
A positional argument follows a named one (f(a: 1, 2)).
The label names a parameter that's already filled — by an earlier positional argument or an earlier named argument.
The named arguments leave an earlier required parameter unfilled while a later one is supplied by name. Parameters with defaults are spliced into skipped middle slots automatically.
The callee has no compile-time named-call interface. A local function declaration provides one automatically; a callable value provides one with a labelled type such as fn(item: Todo) -> View.

fn f(a: int, b: int, c: int = 2) -> int {
    return a + b + c
}

f(a: 1, c: 5)
//      ^^^^ error[TE131]: named-argument call skips parameter `b`; pass it
//            explicitly

Fix it¶

1. Pass the skipped parameter explicitly¶

f(a: 1, b: 1, c: 5)      // ok
f(c: 5, a: 1, b: 1)      // ok — order between named args is free

2. Fix the label name¶

fn f(a: int, b: int) -> int { return a + b }

f(a: 1, bb: 2)
//      ^^ error[TE131]: unknown parameter `bb` — did you mean `b`?

f(a: 1, b: 2)             // fixed

3. Don't name a parameter that's already filled¶

f(1, a: 2)                // error[TE131]: `a` is a duplicate or collides
                           //   with the already-bound positional slot
f(a: 2)                    // fixed — pick one form

4. Don't mix a positional argument after a named one¶

f(a: 1, 2)                 // error[TE131]: positional argument after named argument
f(a: 1, b: 2)               // fixed — label both...
f(1, 2)                     // ...or label neither

5. Give the callable a named-call interface¶

A local function declaration already exposes its parameter names. When calling through a function-typed parameter, label the parameters in the type:

fn render(row: fn(item: Todo) -> View, todo: Todo) -> View {
    row(item: todo)           // ok
}

The label is a compile-time call interface only; it does not change function type compatibility. If the callable truly has no known interface (for example, a dynamic lookup), use positional arguments instead.

Named arguments on methods¶

Named arguments on a method call are resolved by method name before types are known. The call is reordered when exactly one impl (in the program or in the standard library) declares a method of that name whose parameters cover every label used. When several declarations with different parameter lists match, the call is ambiguous:

impl A { fn set(self, x: int, y: int) -> int { x } }
impl B { fn set(self, y: int, x: int) -> int { y } }

a.set(x: 1, y: 2)   // error[TE131]: named arguments on method `set` are ambiguous

Call it positionally, or give the two methods distinct names.

named-argument call requires a locally-declared function signature