66. Macros: use cases and limits

Level: advanced · Reading time: 9 min · Prerequisite: book/chapters/65-règles-abi-interop-vitte.html · Track: supplemental · Maturity: draft · Last review: 2026-05-09

Prerequisites: book/chapters/65-règles-abi-interop-vitte.html. See also: book/chapters/65-règles-abi-interop-vitte.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.

Concrete Problem

Macro chapters become misleading when they present expansion power without naming the readability cost.

Red Thread (Single Project)

One small macro-like helper exists to remove duplication while preserving a stable public shape.

For what

This chapter helps the reader keep macro use intentional and bounded.

What you are going to do

You will inspect one use case where a macro-like surface is justified, then compare it to a noisy misuse.

Coherent example

space demo/macros

macro trace_value(name, value) {
  emit name
  emit value
}

Global explanation

Macros should be taught as controlled power tools. The question is not merely what they can generate, but whether they preserve or destroy the clarity of the resulting program surface.

Invalid case

macro broken {
  give 0
}

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

Common pitfalls

• Using macros to hide ordinary control flow.
• Expanding syntax when a procedure would stay clearer.
• Skipping the readability and debugging cost of generated surfaces.

Short exercise

Take one repetitive pattern from another chapter and argue whether it deserves a macro or a plain procedure.

Summary in 5 points

1. Macros should pay their readability cost.
2. A bounded use case teaches better than a flashy demo.
3. Generated surface still needs a clear contract.
4. Debuggability matters as much as expressiveness.
5. Macro pages should teach restraint, not only power.