Skip to content

CEP-0004: Function Overloading

Draft

Draft proposal for function overload sets and overload resolution. V1 has no function overloading; each callable name resolves to one declaration in a scope.

Summary

Catalyst should eventually support function overloading when multiple declarations with the same callable name can be resolved deterministically from argument types, expected type, visibility, and possibly target metadata such as attribute target kind.

V1 deliberately avoids overload sets so function lookup, diagnostics, function type identity, defaults, contract operation compatibility, and reflection stay simple.

Example

Possible future shape:

fn format(value: i32) String { ... }
fn format(value: f64) String { ... }
fn format(value: UserId) String { ... }

const text = format(user_id)

V1 code must use distinct names or an explicit contract-shaped API:

fn format_i32(value: i32) String { ... }
fn format_f64(value: f64) String { ... }
fn format_user_id(value: UserId) String { ... }

Motivation

Overloading would make several APIs more ergonomic:

  • one box name could cover concrete boxing and direct dynamic boxing;
  • attribute providers could share a source-facing name while specializing by target kind;
  • static and dynamic variants of helper functions could share names when their call shapes differ;
  • overload-to-function-pointer selection could use an expected function type.

Without a shared overload-resolution model, these features would grow one-off lookup rules.

Proposed Direction

The proposal should cover:

  • declaration rules for overload sets;
  • overload candidate collection across local, imported, inherent, contract, and future extension-method scopes;
  • resolution by positional argument types and expected return/function type;
  • interaction with default parameters;
  • interaction with CEP-0015: Named Arguments;
  • interaction with CEP-0016: Generic Parameter Inference;
  • overload-to-function-pointer selection by expected function type;
  • attribute-provider overloading and target-kind filtering;
  • ambiguity and no-candidate diagnostics.

Overload resolution should remain deterministic and visible to tooling. It should not perform runtime dispatch or dynamic conformance lookup unless the selected callable explicitly uses dynamic dispatch in its ordinary signature.

V1 Compatibility

V1 rejects overload sets and duplicate visible attribute provider names. APIs that would like overloads must use distinct names such as box and box_dyn.