Add automatic resource management design

[Copilot]

Design document for deterministic resource cleanup in Zena, addressing opt-in vs automatic semantics, the Disposable protocol, and visibility concerns for disposal methods.

Key Decisions

• Opt-in with using keyword — WASM-GC lacks destructors/finalizers; automatic RAII-style cleanup isn't feasible without an ownership system
• _dispose() protected method — Uses existing _ prefix convention for visibility, hides from autocomplete, no symbol infrastructure needed
• DisposableGroup — LIFO disposal for multiple resources, clearer name than "Stack"
• Lint warnings — Mitigates hazard of forgetting using on disposable types

Proposed Syntax

{
  using file = openFile('data.txt');
  let data = file.read();
} // file._dispose() called automatically

// Multiple resources with group
{
  using group = new DisposableGroup();
  let a = group.use(openFile('a.txt'));
  let b = group.use(openFile('b.txt'));
} // Both disposed in reverse order

Files

• docs/design/resource-management.md — Full design with language survey, Zena constraints analysis, implementation plan
• .github/copilot-instructions.md — Added reference to new design doc

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add automatic resource management design</issue_title>
<issue_description>We want a system kind of like JavaScript's automatic resource management, where objects can implement a Disposable interface and have their dispose() method called automatically when they go out of scope.

JavaScript resource management is opt-in: you have to declare a non-mutable variable with using. Should Zena's system be opt-in or could it be automatic because it's statically compiled and has a sound type system? Is automatic even desired, or is opt-in easier to understand. If it's opt-in how can we reduce the hazard of accidentally not opting in and leaving resources un-disposed.

Do we need something like JavaScript's DisposableStack (I like the name DisposableGroup better)?

Zena currently doesn't have protected class members, symbol-keyed fields, or any kind of field namespacing. What would we want out of Zena on that front to build a Disposable protocol, where the relevant methods shouldn't be very public (they should at least be hidden by default in IDEs and such).

This issue will be satisfied by a design document in the docs/design folder. It should discuss other the approaches other languages take, and why we choose a particular one for Zena given Zena's goals and architecture.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [docs] Add automatic resource management design #11

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.