In Kotest's FreeSpec, `"a stack" - { ... }` declares a group while `"pops the last item" { ... }` declares a test. What is the `-` actually doing there, and what nesting rules follow from it?

## The mechanism Kotlin's **operator conventions** map punctuation to specially named functions: `a - b` compiles to `a.minus(b)` when a suitable `operator fun minus` is in scope, and `a(b)` compiles to `a.invoke(b)` when a suitable `operator fun invoke` is in scope. Combine that with trailing-lambda syntax — the lambda moves outside the parentheses and, as the only argument, drops them entirely — and both FreeSpec forms are plain Kotlin: ```text "a stack" - { ... } ==> "a stack".minus({ ... }) "pops" { ... } ==> "pops".invoke({ ... }) ``` Kotest declares both extensions on the **DSL receiver** that the spec body runs against, so they exist only inside a FreeSpec (and its containers), never in ordinary code. ## Containers versus leaves Kotest's test tree has two node kinds and FreeSpec maps one operator to each: - A **container** (the `-` form) declares children and contributes a name segment. It has no assertions of its own. Its body scope exposes *both* operators again, which is exactly why nesting is unbounded. - A **leaf** (the bare-invoke form) is the terminal test: it holds the assertions and is what a report counts as pass or fail. Its body scope is the *execution* scope, which does **not** expose the registration extensions, so writing a nested `"x" { }` inside a leaf does not compile. A container may mix leaves and further containers freely at the same level. ```kotlin class StackTest : FreeSpec({ "a stack" - { "when empty" - { "throws on pop" { } "reports size zero" { } } "when holding items" - { "pops in LIFO order" { } } "is serialisable" { } // leaf directly under a container } "a top-level smoke test" { } // leaf at the spec root }) ``` ## Derived names Unlike styles that inject a keyword into the rendered name, FreeSpec contributes **nothing**: the displayed path is exactly the strings you wrote, joined along the tree from the spec down to the leaf. That has two practical effects. First, **readability is entirely on you**. Nothing forces the path to read as a sentence; the common convention is to make container strings noun phrases or condition phrases ("when empty") and leaves behaviour phrases, so the path still reads like prose. Second, **a leaf's identity is its full path**, not its bare name. Two different containers may each hold a leaf called `"returns null"` without colliding, because their paths differ. Within a *single* scope, duplicate names do collide, and Kotest's `DuplicateTestNameMode` (`Warn`, `Silent`, `Error`) governs what happens — it can be set per spec or project-wide. ## Registration is executed code The spec body and every container body are ordinary lambdas, so control flow works: a loop inside a container registers one child per iteration, with interpolated names. Two caveats follow. Each generated name must be distinct within its scope, and a container body is **not a lifecycle hook** — code you place at the top of a `-` block runs at that point in the execution, and whether it re-runs for each descendant leaf depends on the spec's isolation mode. Shared setup belongs in Kotest's lifecycle callbacks, not in a container body. All bodies are **suspending**, so leaves and containers may call suspend functions directly. ## The trade FreeSpec makes FreeSpec is the most syntactically minimal of the container-bearing styles: one character of punctuation is the entire difference between a group and a test. Teams that like it cite exactly that — no `describe(`/`it(` scaffolding, no framework-supplied words, arbitrary structure that mirrors the domain. The complaints are the mirror image: 1. **The dash is easy to miss.** Deleting or forgetting it silently changes a container into a leaf (or fails to compile, if the body registers children). Reviewers scanning quickly can misread the structure. 2. **No guardrails on depth.** Because nesting is unbounded and unnamed by keywords, a FreeSpec can grow into a deep tree whose leaves only make sense with the full path in view. Most teams that adopt it also adopt a convention capping depth at two or three levels. 3. **No enforced grammar.** Styles that supply words nudge everyone into the same phrasing; FreeSpec does not, so consistency has to come from review. ## Answering well Say the mechanism (`minus` and `invoke` operator conventions on scoped String extensions), state the rule that containers nest arbitrarily while leaves are terminal and enforce that at **compile time**, note that names are joined with nothing added and that a leaf's identity is its full path, and finish with the honest trade — maximum freedom, minimum guardrails.