Overload sets are not exportable across modules

LIMIT-TYPE-CONSTRUCTION-002

Overload sets are seeded by two different mechanisms; exporting them across modules (METEL-188) is future work.

Lifecycle

known

Owner

metel-frontend

Scope

architecture/spec/type-construction.md#type-construction

Origin

ADR-0038

Affects · linked records

arch.type-construction.requirement-1architecture requirement

arch.name-resolution.requirement-1architecture requirement

GAP-FUNCTIONS-001gap

limitationKnown limitations ↗

Limitation

An "exportable overload sets" mechanism — overloads carried in GlobalExports, resolved through ordinary imports like any other declaration — is future work, not scheduled. Today the graph-import path and the single-program path (which performs no imports) seed overload sets through two different mechanisms rather than one shared one, because the shared mechanism doesn't exist yet.

Impact

A module cannot re-export or extend another module's overload set through an ordinary import; only the declaring module's own resolution can dispatch into it by SymbolId.

Affects

• arch.type-construction.requirement-1 (GlobalExports)
• arch.name-resolution.requirement-1 (SymbolId assignment for overloaded declarations)
• GAP-FUNCTIONS-001 (overloading is not specified in the Language Spec)

Resolution

None yet: the earlier tracking issue (metel-core#258) was closed pending a language-design RFC that defines the model and settles shadow-versus-extend semantics; an implementation issue is opened once that RFC is accepted. If it lands, ADR-0038 states the graph-path seeding becomes an ordinary import and the single-program path keeps its existing seeding unchanged.