plum

# Generic enums: support more than one concrete instantiation per program

## Problem

Generic enum monomorphization (from the prior generics-monomorphization work) has a real,

documented limitation: a given generic enum may only be instantiated at **one** concrete type per

program. Instantiating the same generic enum at two different concrete types (e.g. both

`Option<Int>` and `Option<Str>` needed in the same file) is detected and rejected with a clear

`monomorphize:` error rather than silently corrupting anything — but it's still a real limitation

for exactly the kind of general-purpose `Option`/`Result` a real program would want.

Root cause: `plum_checker::build_global_tables` builds `EnumVariants` — the table matching a

`match` pattern's or a construction call's bare variant name (`"Some"`, `"None"`) to its owning

enum, tag, and field types — keyed by **bare variant name, globally across the whole program**.

Two specializations of the same generic enum (`Option$Int`, `Option$Str`) both declare a variant

literally named `Some`, so they'd collide in that flat table. The existing monomorphizer detects

this collision and rejects it rather than letting one specialization silently clobber the other's

registration — correct, but overly conservative.

## Fix

Mangle variant names too, using the same suffix as their enum's own mangled name — `Some` →

`Some$Int` / `Some$Str`, `None` → `None$Int` / `None$Str`. This is necessary even for

payload-free variants like `None`: although their runtime representation (a small tag, no

payload) is identical regardless of the concrete type argument, their *static type* differs per

instantiation (a bare `None` used as a value must type as `TNamed("Option$Int")` or

`TNamed("Option$Str")`, not an ambiguous, instantiation-independent `Option`), so leaving them

unmangled would still create real inference ambiguity even though it wouldn't corrupt anything

at the runtime-representation level.

This touches three points, all inside the already-built `plum_checker::monomorphize` pass — no

new pipeline integration is needed, since `monomorphize_source` already runs ahead of both

`check_source` and `compile_source`:

1. **`specialize_enum`**: extend it to rename each variant using the same mangled suffix as the

   enum's own name, not just the enum itself.

2. **Construction call-site rewriting** (`resolve_enum_instantiation`): currently deliberately

   does *not* rewrite `call.name` for a variant constructor like `Some(5)`, on the theory that

   variant names stay bare. That has to change now: once the enum's own instantiation is

   resolved, also rewrite the construction call's name from `"Some"` to its mangled form.

3. **Match-pattern rewriting** (new): `rewrite_stmt`'s existing `Match` handling infers the

   subject's type (already needed for binding a non-variant pattern name) but never touches the

   patterns themselves. It needs to: check whether the inferred subject type is a specialized

   generic enum, and if so, rewrite every `Some`/`None`-shaped pattern (`ast::CasePattern::Name`

   for a payload-free tag, `ast::CasePattern::Class` for a constructor pattern) in that match's

   cases to the corresponding mangled variant name, using a per-enum variant-mangling table

   recorded at the moment that enum specialization was produced.

With variant names uniquely mangled per specialization, the existing collision-detection

machinery (the `enum_variant_owner` ownership table, and the error path it guards) becomes

unnecessary and should be removed — there is no more collision to detect, since every

specialization's variants live under their own unique mangled names.

## Addendum: ordinary functions with a bare generic-typed param must be specialized too

Implementation surfaced a real, blocking gap the above design didn't account for, discovered

because it broke the **pre-existing** single-instantiation codegen test: an *ordinary* function

(one with no lowercase-letter generic params) that takes a bare generic-enum-typed parameter — the

completely normal way to write this, e.g.

```plum

unwrapOr(o: Option, default: Int) -> Int =

  match o

    Some(v) => v

    None => default

```

— never has its own param type resolved to a concrete specialization at all. `o`'s declared type

stays the literal, unmangled `Option`, so inside `unwrapOr`'s body, `match o` infers a subject

type of `TNamed("Option")` — a key that can never match the mangling table (keyed by the mangled

name, `"Option$Int"`). This isn't an ordering bug (verified directly, including by reordering

source); it's that ordinary functions are never treated as needing specialization at all today,

even though a bare generic-enum-typed param makes them behave exactly like a specialization

target. The same root cause almost certainly affects generic **classes** too, for the identical

shape (`f(b: Box) -> Int = ...`) — untested before now only because no existing test happened to

exercise it, but the failure mode is analogous (post-monomorphization, the bare generic class

`Box` no longer exists in the output at all, since only its mangled specializations survive).

**Fix, symmetric for both classes and enums:** treat an ordinary function whose param or return

type bare-names a generic class or enum as needing its own per-call-site specialization, exactly

mirroring how a truly-generic function (lowercase-letter params) is already specialized:

- **Return position** is half-solved already: `maybe_rewrite_return` already resolves a bare

  generic-*class* return (e.g. `-> Box`) from the body's inferred tail type, via the existing

  `self.classes_generic.contains_key(&rt.name)` check — it just never checked the enum registry.

  Add the parallel `self.enums_generic_by_name.contains_key(&rt.name)` check alongside it.

- **Param position** (the actual blocker) is new: detect, for an otherwise-ordinary function,

  every param whose declared type bare-names a generic class or enum (a new `fn_bare_generic_refs`

  helper, parallel in spirit to `fn_generic_params` but checking against the classes/enums

  registries instead of the lowercase-letter convention). Such a function is deferred (not passed

  through directly) and resolved at each call site: infer the calling argument's already-rewritten

  concrete type (e.g. the first argument to `unwrapOr(Some(13), 0)` is, after its own construction

  site is rewritten, `TNamed("Option$Int")`), bind `{"Option": TNamed("Option$Int")}` into a

  `Substitution`, mangle the function itself (`mangle("unwrapOr", &[TNamed("Option$Int")])` ->

  `"unwrapOr$Option$Int"`), and specialize it via the **existing, unmodified** `specialize_fn` —

  its substitution mechanism already walks and replaces any type whose bare name matches a

  substitution key, so no changes to `specialize_fn` itself are needed, only to how the

  substitution is discovered and populated for this new case.

Scoped to free functions only for this fix — a **method** introducing this same shape (a method

on a non-generic class whose own param bare-names a generic class/enum) is a further edge case,

consistent with the existing "a method introducing its own additional generic parameter" already

being out of scope. A function that is simultaneously truly-generic (lowercase letters) *and*

bare-references another generic type is also out of scope for now (no current example needs it).

## Testing plan

- **Checker tests**: a generic `Option`-shaped enum instantiated at two different concrete types

  in the same program (both `Option<Int>` and `Option<Str>` constructed and matched) type-checks

  correctly, each `match`'s patterns resolving against the correct specialization.

- **Codegen tests**: the same two-instantiation scenario, compiled and executed via `wasmtime`,

  confirming both specializations produce correct, non-aliasing results (mirroring the existing

  "generic class specialized at two types" test's shape, now extended to enums).

- Re-verify (don't just assume unaffected): a single-instantiation generic enum still works

  exactly as before now that the collision-guard code path is gone — the existing

  single-instantiation tests from the prior plan must still pass unchanged.

- Remove or repurpose the now-obsolete "multi-instantiation collision is a clear error" test from

  the prior plan, since that behavior is being replaced by "multi-instantiation now works

  correctly" — replace it with the new coexistence test above.

- The exact regression that surfaced the addendum's gap: an *ordinary* function taking a bare

  generic-enum-typed parameter (`unwrapOr(o: Option, default: Int) -> Int`), compiled and run via

  `wasmtime`, at both a single instantiation (proving no regression to the already-working case)

  and multiple coexisting instantiations. Add the analogous test for a generic **class** (an

  ordinary function taking a bare generic-class-typed parameter, e.g. `sumBox(b: Box) -> Int`),

  since the addendum's fix is symmetric and this shape was never tested before.

## Out of scope

- Everything else the generics-monomorphization plan already scoped out (a method introducing

  its own additional generic parameter; trait-bound enforcement; `libs/std` compiling as-is) —

  unchanged, unaffected by this fix.

- Closures and the `list.plum`/`map.plum` rewrite — separate, subsequent follow-ups.