local/global modality #28

New issue

Open

opened 2026-06-29 15:00:07 +02:00 by st · 1 comment

st commented

2026-06-29 15:00:07 +02:00

Owner

conceptually two distinct concepts: stack vs heap allocation, own vs borrow

let unboxed x = ... creates x with local modality; it is not allowed to leak, and can only be passed to functions whose parameters are local modality

Heap allocations are global modality, and can coerce to local, i. e. GC still needs to trace locals, i. e. locals are also GC roots, but things that live on the stack can not be moved; we must simply trace through it

unboxed vs the default but never named boxed controls one concept: heap vs inline (on stack or inline in struct)

for owned vs borrow the local/global lingo is a little bizarre; maybe we could use rust terminology

conceptually two distinct concepts: stack vs heap allocation, own vs borrow `let unboxed x = ...` creates `x` with `local` modality; it is not allowed to leak, and can only be passed to functions whose parameters are `local` modality Heap allocations are `global` modality, and can coerce to `local`, i. e. GC still needs to trace `local`s, i. e. locals are also GC roots, but things that live on the stack can not be moved; we must simply trace through it `unboxed` vs the default but never named `boxed` controls one concept: heap vs inline (on stack or inline in struct) for owned vs borrow the local/global lingo is a little bizarre; maybe we could use rust terminology

st added the

rfc

label

2026-06-29 15:00:12 +02:00

st commented

2026-06-30 14:27:03 +02:00

Author

Owner

this interacts in an awkward way with the potential Memory[T] type since borrowed references to a Memory should not be traced though but is not on the stack. reasonably easy fix is to give Memory its own heap

this interacts in an awkward way with the potential `Memory[T]` type since borrowed references to a `Memory` should not be traced though but is not on the stack. reasonably easy fix is to give `Memory` its own heap