CEP-0039: Smart-Pointer Forwarding¶

Summary¶

Catalyst should eventually decide whether owner or smart-pointer types can forward methods or contract operations to their contained payloads.

V1 avoids general owner forwarding. Box exposes explicit ptr() and ptr_const(), with a closed forwarding surface for boxed dynamic iterator owners.

In particular, V1 does not define a general rule that Box(dyn C) implements C. A boxed erased owner is not itself the erased payload surface unless a specific prelude impl says so. Ordinary contract operations on the payload require an explicit borrow:

var seq: Box(dyn Sequence(T)) = ...
const n = seq.ptr_const().len()

Direct owner calls are valid only for the closed V1 boxed iterator forwarding surface documented in Boxed Iterator Forwarding.

Example¶

Possible future shape:

const button = Box(Button).create(allocator, Button.init())
button.draw()

V1 keeps the borrow explicit:

button.ptr().draw()

Motivation¶

Forwarding can improve ergonomics for Box(T), reference-counted owners, pinned owners, and dynamic boxes. It can also hide borrowing, mutation, ownership, allocation, and dispatch.

Proposed Direction¶

The proposal should cover:

• which owner types can forward;
• whether dynamic owner types such as Box(dyn C) can ever implement C generically;
• whether forwarding is inherent, contract-based, or extension-method-based;
• receiver borrowing and mutability rules;
• conflict resolution with owner methods;
• dynamic dispatch and upcast behavior;
• reflection and diagnostics for forwarded methods.

V1 Compatibility¶

V1 users borrow through explicit ptr() or ptr_const() except for the closed boxed iterator forwarding model.

Closed V1 forwarding is an ordinary set of prelude contract implementations for selected boxed iterator owner types. It is not a smart-pointer forwarding rule, not a for special case, and not precedent for general Box(dyn C) implements C.

Related Details¶

• Box Resource
• Boxed Iterator Forwarding
• CEP-0011: General Extension Methods