Section 42: Operator Overloading and Custom Operator Behavior¶

TECHSPEC-42 — Section 42 · Version 0.1 · Status: Initial Draft

Status: draft. This section is an Initial Draft (Section 57 is a Working Register). It describes intended or proposed behavior, not a finalized, implemented language rule. Do not treat examples here as normative.

1. Purpose¶

Operator overloading allows user-defined types to participate in familiar expressions. It can also make code misleading when operators perform surprising work.

The language therefore restricts overloading and requires explicit contracts.

2. MVP Policy¶

The MVP supports built-in operators only. User-defined operator overloading is deferred until the type, interface, and contract systems are stable.

3. Permitted Overloads¶

A later version may permit a limited set of overloadable operators, including: - Arithmetic operators. - Equality and inequality. - Ordering comparisons. - Indexing where its semantics are clear.

The language must maintain a fixed list of overloadable operators. Syntax, precedence, and associativity cannot be changed by a library or user-defined type.

4. Required Declarations¶

Each overload must declare: - Operand types. - Return type. - Preconditions. - Postconditions. - Effects. - Failure conditions. - Relevant invariants.

An overload must not perform hidden network, filesystem, database, process, or other external operations.

5. Semantic Expectations¶

Overloads should preserve the ordinary meaning of their operators.

Examples: - Equality should represent a documented equality relation. - Ordering should define a consistent ordering where one is claimed. - Arithmetic should document units, overflow behavior, and invalid operations. - Indexing should document bounds and failure behavior.

The compiler may check signatures and declared laws, but it must not claim algebraic laws are proven merely because an overload declares them.

6. Equality and Hashing¶

Types used as map keys or set members must provide compatible equality and hashing behavior.

Required relationship: - Values considered equal must produce equal hash values. - Hashing must remain stable while a value is used as a key. - Mutating a key in a way that changes its hash or equality behavior must be prohibited or explicitly handled.

7. Side Effects¶

Operator expressions should be free of externally visible side effects by default.

If the language later permits effectful overloads: - Effects must be declared. - Evaluation order must remain defined. - Failure behavior must be explicit. - Diagnostics must make the effect visible to the caller.

8. Overload Resolution¶

Resolution must be deterministic.

Rules: - No implicit lossy conversions to select an overload. - Ambiguous matches are compile errors. - Generic constraints must be satisfied. - The selected overload must be visible in compiler diagnostics and introspection.

9. Verification¶

The compiler checks declarations, types, effects, and applicable contracts. Tests and formal verification provide separate evidence about behavior.

10. Design Goal¶

An operator must not conceal arbitrary behavior. A reader and an AI agent should be able to understand what an expression does from its type and declared contract.

Source file: TECHSPEC-42.md (preserved in source-original/LANG/). See the specification index, the glossary, and the cross-reference index.