Skip to content

CEP-0033: Opening Dyn for Static Generics

Draft

Draft proposal for using dynamic contract objects as inputs to static generic contract parameters. V1 rejects already-erased dyn arguments for static dispatch.

Summary

Catalyst should eventually decide whether a dyn contract object can be opened for APIs that expect static generic contract parameters.

V1 static dispatch requires a compile-time-known concrete implementer. A dyn object has erased the concrete type, so it cannot satisfy anonymous or named static constraint parameters.

Example

Possible future shape:

fn render_static(comptime T: Type implements Draw, value: *T) {
  value.draw()
}

fn render_erased(value: *dyn Draw) {
  open value as T, ptr {
    render_static(T, ptr)
  }
}

The proposal must decide whether such opening is possible, whether it needs runtime identity, and what it costs.

Motivation

Opening dyn values could improve generic helper reuse, but it risks pretending dynamic erasure can recover static specialization. The feature needs explicit semantics for dispatch, layout, and failure.

Proposed Direction

The proposal should cover:

  • whether opening is allowed at all;
  • whether it uses runtime type identity;
  • whether opened calls dispatch dynamically, re-specialize, or use generated adapters;
  • limitations for unsized payloads and owned dynamic boxes;
  • diagnostics and performance visibility.

V1 Compatibility

V1 rejects already-erased dyn arguments for static generic parameters. Use explicit dynamic APIs or borrowed/owned dynamic contract surfaces.