Labelled arguments without a mandatory call-site constraint

Answer

Short answer: In the current stable Gleam compiler there is no documented or experimental flag that forces callers to use labelled arguments. The language treats a labelled call and a positional call as identical at the type level, so the compiler will accept either form without warning.

Why labels are optional

Labels in Gleam are syntactic sugar. They only affect the source‑code text; the generated function signature, type, and runtime representation remain unchanged. Consequently:

• The compiler’s type checker sees add(a: Int, b: Int) and add(Int, Int) as the same function.
• Currying, higher‑order functions, and interop with Erlang or JavaScript treat both forms identically.
• No existing compile‑time option or hidden flag can change this behavior.

Recommended patterns for library authors

1. Documentation and README guidance

State the preferred style explicitly in the public documentation. Example:

/// Adds two numbers. Prefer labelled arguments for clarity.
/// ```gleam
/// add(a: 5, b: 3)
/// ```
pub fn add(a: Int, b: Int) -> Int { a + b }

2. CI‑level linting

Introduce a simple lint rule that flags positional calls to add and any other public function that should be called with labels. The rule can be run as part of your CI pipeline or in the editor via the Gleam extension.

3. Record‑wrapper refactor (if you can change the API)

Replace the function signature with a single record argument:

pub fn add(args: { a: Int, b: Int }) -> Int { args.a + args.b }

Now callers must write:

add({ a: 5, b: 3 })

Positional calls are no longer possible, but the API surface changes and may break existing consumers.

Future compiler changes

There is currently no plan in the issue tracker to deprecate positional calls or introduce a --require-labels flag. However, language evolution could add stricter rules or a dedicated option in a future release. If such a feature appears, existing positional calls compiled with older versions would still work, but new code would need to adapt.

Verification steps (for your own sanity)

1. Create a module:

   pub fn add(a: Int, b: Int) -> Int { a + b }

2. Compile and call with both forms:

   add(1, 2)
   add(a: 1, b: 2)

3. Run gleam build – no warnings or errors appear for either call.
4. Optional: refactor to a record wrapper and observe that callers must use named fields.

These steps confirm the current compiler behavior and illustrate the impact of the record‑wrapper approach.

Conclusion

Until the compiler itself provides a mandatory‑label feature, library authors should rely on clear documentation, linting, or a record‑wrapper pattern to guide callers toward the desired call‑site style. Keep an eye on the Gleam issue tracker for any future changes that might alter this landscape.