[tausbn]

When creating the target tree for some rewrite rule, we quite often want to make the construction conditional on the presence of certain captures, or on the current state of the context.

Previously we added the postfix ? operator for this purpose. This made it possible to write a tree template like

(foo 
  bar: (baz id: (identifier #{name}))?
)

wherein the entire baz node disappears (because of the postfix ?) if the name interpolation fails (e.g. if name is None).

There are a few drawbacks with this approach:

• There's no way to specify a non-None alternative.
• It only works for #{...} interpolations.
• It works on the basis of constructing the tree eagerly and then cancelling the construction if any of the interpolations failed. This could lead to orphaned nodes in the output AST if these were constructed before the interpolation was attempted.

(This also made the implementation somewhat complicated, requiring the use of labels and breaks in the lowered Rust code.)

Instead of the above, this PR implements a generalisation of this concept. Taking inspiration from the tree-sitter query language, we use square brackets to indicate a list of alternatives that should be attempted in turn. The first alternative that succeeds is the tree that is returned from this choice operator. Moreover, individual choices can have a bool-returning Rust-block as a guard.

Thus, something like

[
  tree1 if {cond1}
  tree2
  tree3 if {cond2}
]

would have the following interpretation

• If cond1 holds, and all #{...} interpolations in tree1 are valid (e.g. different from None), then return tree1
• Otherwise, if all #{...} interpolations in tree2 are valid, return that
• Otherwise, if cond3 holds and all #{...} interpolations in tree3 are valid, return that
• Otherwise return None

This fully supersedes the existing ? syntax (which we therefore remove first): (...)? can be rewritten to just [(...)].

Before constructing any trees, the implementation first checks that the relevant condition (if present) holds, and that all #{...} interpolations have usable values. Only if both of these are true is the tree construction attempted. This prevents any orphaned nodes from being constructed.

[Copilot]

🟡 Changes recommended

Two critical compilation failures remain: missing OutputId support breaks translated captures, and premature candidate construction causes moved-value errors when alternatives consume the same repeated capture.

2 open issues

• Avoid moving repeated captures before guard evaluation · New
• Preserve OutputId support for translated captures · New

What changed in this PR

Adds ordered, guarded choices to Yeast tree templates, replacing postfix ?. The new syntax lets rewrite rules express fallbacks and check interpolation dependencies before constructing template nodes.

Changes:

• Add choice parsing, validation, and lowering with guard and dependency checks.
• Update documentation and tests for fallback selection, nested choices, and orphan-node prevention.
• Migrate Swift translation rules to bracketed choices.

File	Description
unified/​extractor/​src/​languages/​swift/​swift.rs	Migrates optional nodes and conditional rewrites to choices.
shared/​yeast/​tests/​test.rs	Covers guards, fallbacks, nested choices, and construction preflight.
shared/​yeast/​src/​lib.rs	Updates interpolation diagnostics and optional-value implementations.
shared/​yeast/​doc/​yeast.md	Documents choice syntax, behavior, and examples.
shared/​yeast-macros/​src/​template_parse.rs	Parses and validates choices and guards; removes postfix ? parsing.
shared/​yeast-macros/​src/​lower.rs	Generates dependency checks and alternative-selection code.
shared/​yeast-macros/​src/​lib.rs	Updates public macro documentation for choices and return types.
shared/​yeast-macros/​src/​ast.rs	Adds choice alternatives and removes the optional-field flag.

_{Review effort: Max}