12. Pointers, references and memory

Level: beginner · Reading time: 14 min · Prerequisite: book/chapters/11-collections.html · Track: essential · Maturity: reviewed · Last review: 2026-05-09

Prerequisites: book/chapters/11-collections.html. See also: book/chapters/11-collections.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.

Concrete Problem

Low-level chapters become dangerous when they show syntax without ownership, lifetime, or boundary reasoning.

Red Thread (Single Project)

One explicit pointer-facing helper isolates a low-level boundary while keeping the rest of the flow simple.

For what

This chapter helps the reader understand why pointer-like surfaces should remain explicit and narrow.

What you are going to do

You will inspect one narrow low-level helper, then compare it to an unsafe misuse.

Coherent example

space demo/pointers

unsafe proc write_value(dst: ptr[int], value: int) -> int {
  give 0
}

Global explanation

Pointer chapters are about boundaries. The goal is not to normalize low-level code everywhere, but to show how a narrow low-level surface can remain explicit and reviewable.

Invalid case

proc bad_ptr() -> int {
  let dst: ptr[int] = 0
  give dst
}

This invalid case is intentionally small. It exists to isolate the contract failure that the chapter is trying to teach.

Common pitfalls

• Treating low-level code as ordinary glue with no special boundary.
• Explaining syntax before explaining risk.
• Failing to isolate the low-level edge from the rest of the program.

Short exercise

Wrap the low-level helper behind a higher-level procedure that exposes a safer contract.

Summary in 5 points

1. Low-level surfaces need narrow boundaries.
2. The chapter should explain risk and ownership first.
3. Unsafe examples should stay explicit.
4. The reader should learn where the boundary belongs.
5. Reviewability matters more than token novelty.