Wado

WEP: Function Return Type Syntax

Status: Accepted Date: 2026-01-16

Context

Wado needed to decide on the syntax for specifying function return types. Two primary options were considered:

  1. Arrow syntax (->) - Used by Rust, Swift, Haskell, Python, and C++ (trailing return type)

    fn add(a: i32, b: i32) -> i32 { ... }

  2. Colon syntax (:) - Used by TypeScript, Kotlin, and other JavaScript-adjacent languages

    fn add(a: i32, b: i32): i32 { ... }

This decision impacts:

Comparative Analysis

Arrow Syntax (->) Advantages:

Colon Syntax (:) Advantages:

Key Decision Factor: Higher-Order Functions

Wado's design includes:

Example comparison with higher-order functions:

// Arrow syntax (clearer separation)
fn apply(f: fn(i32) -> i32, x: i32) -> i32 with Stdout

// Hypothetical colon syntax (more ambiguous)
fn apply(f: fn(i32): i32, x: i32): i32 with Stdout

The arrow syntax provides better visual parsing when function types and return types appear in the same signature.

Research Findings

From community discussions:

Rust Internals: The -> syntax was chosen to make the language "easier to parse for humans, especially in the face of higher-order functions." It originates from functional languages (Haskell, ML, OCaml) and serves as a visual "case marker" separating different parts of the function signature.

Kotlin Community: A proposal to change from : to -> was rejected due to parsing complexity in higher-order functions (e.g., fun bla(arg:(Int)->String):(String)->Int becomes difficult to parse).

C++ Design: Trailing return type syntax (auto f() -> T) was introduced specifically to solve scoping issues with dependent return types and to support left-to-right reading order.

Decision

Wado adopts arrow syntax (->) for function return types:

fn function_name(param: Type) -> ReturnType { ... }

This applies to:

Closures will use a separate syntax decision (see WEP 2026-01-16: Closure Implementation), but the arrow syntax remains consistent for any return type annotations.

Consequences

Positive

Negative

Neutral

Alternatives Considered

  1. TypeScript-style colon (:) - Rejected due to reduced clarity in higher-order functions and weaker alignment with systems programming languages
  2. Hybrid approach (: for functions, -> for closures) - Rejected due to inconsistency
  3. No syntax (positional like Go) - Rejected as it reduces type annotation explicitness

References