Call Arguments

Calls bind named arguments by API name and positional arguments by position. Arguments use @name, a % [...] positional group, the single bare ARG form, or COMPOSITE_UNPACK(composite).

Named arguments

VAR result I32 := ceil_div(@numerator 9, @denominator 2);

A named argument has the form @name expression. Named arguments need not be written in parameter-declaration order:

VAR result I32 := ceil_div(@denominator 2, @numerator 9);

Both calls bind the same parameters. The name is the parameter's public API name, not necessarily its body-local name:

::ceil_div FUNCTION(@numerator:n I32, @denominator:d I32): I32
{
  RETURN (n + d - 1) / d;
}

Each named argument must identify an explicit parameter or be captured by the selected candidate's final @KWARGS ... parameter. A name cannot be supplied twice. Argument names are compile-time call metadata and do not add a runtime calling-convention cost.

The single bare @ARG form

A call containing exactly one unprefixed expression binds that expression to the conventional named parameter @ARG:

::twice FUNCTION(@ARG I32): I32
{
  RETURN ARG * 2;
}

ASSERT(twice(7) == 14);

If a call has more than one argument, or the one parameter is not named @ARG, use explicit argument syntax. A bare argument cannot be followed by another argument.

Template argument lists share this grammar, but their single bare argument binds the conventional named template parameter @T instead. Thus box#(I32) is equivalent to box#(@T I32); an explicitly positional template argument is written box#(% [I32]).

Positional groups

Positional expressions appear inside % [...]:

::sum FUNCTION(%left I32, %right I32): I32
{
  RETURN left + right;
}

ASSERT(sum(% [4, 5]) == 9);

The expressions bind the next positional parameters in their order in the signature. The brackets may be empty for an empty positional group. Named arguments are not permitted inside a positional sequence, and a trailing comma without another positional expression is rejected.

Several positional groups may appear in one call; their elements form one logical positional sequence:

combine(% [first], @mode selected_mode, % [second, third]);

This is especially useful when a positional variadic pack surrounds or follows named API arguments.

Mixed calls and evaluation order

Named arguments and positional groups may be interleaved. Argument expressions are evaluated in written source order, even though named binding is independent of declaration order:

VAR combined I32 := combine(
  % [first_expression()],
  @named second_expression(),
  % [third_expression(), fourth_expression()]
);

The four calls occur in that order. After evaluation, the values are mapped to the selected candidate's named and positional formal parameters.

Composite arguments and APPLY

APPLY arguments TO target expands the top-level fields of a composite into positional and named arguments. It evaluates the argument composite first, then the target, using ordinary parameter adaptation and defaults. It does not invoke constructors. See Composites for reference forwarding, receiver restrictions, and the KWARGS capture rules.

Empty calls and defaults

function() supplies no arguments. It is valid when the selected candidate has no required parameters. A parameter omitted from the written arguments is filled only when it declares DEFAULT(expression); otherwise that candidate is not viable.

Named arguments can omit an earlier defaulted parameter while supplying a later named parameter. Positional arguments cannot skip an earlier required positional slot. See Default Arguments.

Constructor argument forms

Direct construction and placement prefix the same argument grammar with ::

VAR named point :(@x 3, @y 4);
VAR positional point :[3, 4];

:(...) accepts the mixed named and % [...] call grammar. :[...] is a positional-only shorthand and rejects named arguments. The same distinction is used by constructor delegation, PLACE AT, and NEW.

Overload interaction

Argument mapping happens for each overload candidate. Names not accepted by explicit parameters or KWARGS, duplicate names, missing required parameters, too many positional values, or an incompatible pack shape remove or reject that candidate before type ranking. The mapped argument values then participate in Overload Resolution.

See Functions for parameter declarations and Variadic Packs for consuming positional packs. See Templates for template declarations and the @T bare-argument convention.

Composite expansion

COMPOSITE_UNPACK(composite) supplies positional and named arguments from a composite. It can be mixed with explicit arguments and other expansions in source order, including in constructors and NEW. Duplicate named arguments are rejected. See Composites.

In a constructor call, the ordinary unnamed argument ARG tries EXPLICIT then OTHER; see Constructor Argument Routing.

Reserved argument names

In addition to lowercase API names, call arguments accept designated uppercase names. Diagnostic and runtime interfaces include ADDR, EXPR, FILE, LINE, COLUMN, TAG, MESSAGE, GUARD, NODE, DEINITIALIZER, FRAME, RECORD, and EXCEPTION. A body-local alias can give one a lowercase name, for example @EXPR:expr STRING_CONSTANT. RETURN remains reserved for the result slot.