Skip to content

CEP-0049: Standard Result Policy

Draft

Draft proposal for richer std.Result(T, E) policy. V1 reserves the canonical root type-factory spelling but uses language-level error returns for ordinary fallible calls.

Summary

Catalyst should eventually decide the representation, constructors, methods, conversions, and usage policy for std.Result(T, E).

V1 reserves std.Result(T, E) as the canonical root type-factory spelling for stored or aggregated outcomes. V1 error handling remains language-owned through error sets and T!E.

Example

Possible future shape:

const result: std.Result(User, ParseError) = parser.parse_result(input)

if result.is_ok() {
  return result.value()
}

The proposal must decide when this is preferable to language-level User!ParseError.

Motivation

A standard result type may be useful for APIs that need to store, compose, or return result values without using language-level error return syntax. It must not duplicate or confuse the core error model.

Proposed Direction

The proposal should cover:

  • representation and layout policy;
  • constructors and accessors;
  • conversion to and from T!E;
  • stored-result and aggregation use cases;
  • pattern matching behavior;
  • formatting/debug behavior;
  • method names and failure behavior;
  • interaction with optionals and error-set unions.

V1 Compatibility

V1 accepts only the canonical type-factory spelling:

std.Result(comptime T: Type, comptime E: Error) Type

T must be a concrete sized value type. E must be an error-set type, including a closed error set, a closed error-set union, or Error.

V1 does not accept Result constructors, methods, implicit conversions, pattern matching behavior, memory representation, or formatting/debug behavior. Ordinary fallible APIs should continue to use T!E.