Brummel 8f40e8c31f DESIGN: substantive rationale for Term::ReuseAs wrapper form
The schema sketch in Decision 10 already committed to
Term::ReuseAs { source, body } as a wrapper, but did not record
WHY the wrapper form was chosen over a reuse_from: Option<String>
modifier on Term::Ctor. Adds the two substantive reasons:

- Compositional flexibility: wrapper generalises to record
  literals, opaque box wrappers, capability cells — anything
  future iters might add as an allocating construct. Modifier
  would replicate per Term variant.

- Source-locality: (reuse-as SRC NEW-CTOR) reads as a sentence
  with the source-binder at the head. Modifier scatters intent.

The trade-off accepted: schema permits Term::ReuseAs around a
non-allocating body. Caught at typecheck via
reuse-as-non-allocating-body diagnostic. Same shape as
Decision 7's Term::If composability accepts.

Recording before 18d.1 ships — per CLAUDE.md "design rationale
ne implementation effort", a schema choice has to name its
substantive reasons before code is written, not retroactively.
2026-05-08 10:40:35 +02:00
S
Description
No description provided
26 MiB
Languages
Rust 91.6%
Python 4.6%
C 1.8%
LLVM 1.6%
Shell 0.4%