plum
git clone https://git.pyrossh.dev/plum
A statically typed, imperative programming language inspired by rust, python
a10644c
— Peter John
2026-07-20T15:07:50+05:30
docs: extend generics monomorphization spec to cover generic enums
docs/superpowers/specs/2026-07-20-generics-monomorphization-design.md
CHANGED
|
@@ -60,6 +60,16 @@ relevant) — user source keeps calling `Box(...)`/`wrap(...)` normally; the com
|
|
|
60
60
|
specialization a given call site needs from its own already-inferred concrete argument types and
|
|
61
61
|
rewrites the call/construction internally to reference the matching mangled specialization.
|
|
62
62
|
|
|
63
|
+
**Generic enums** (`enum Option = | Some(a) | None` — matching `libs/std`'s real `Option`) are in
|
|
64
|
+
scope alongside classes/functions/traits. Unlike `Class`/`Trait`, `ast::Enum` has no explicit
|
|
65
|
+
`generics: Vec<GenericParam>` field, and neither does `ast::Fn` — both are detected as generic
|
|
66
|
+
implicitly, the same way: a variant's field type name (`EnumVariant.fields: Vec<String>`, for
|
|
67
|
+
enums) or a function's param/return type name (for `Fn`) that is a single lowercase letter (`a`,
|
|
68
|
+
`b`, `c`, `d` — the grammar's only legal generic-parameter spelling) is treated as an implicit
|
|
69
|
+
generic parameter, exactly like a `Class`'s explicit `generics` list entry. Specialization,
|
|
70
|
+
mangling, and the worklist apply identically regardless of which item kind introduced the generic
|
|
71
|
+
parameter.
|
|
72
|
+
|
|
63
73
|
A generic **method** (`get<List>(i: Int) -> a`) specializes alongside its receiver class: once
|
|
64
74
|
`List` is specialized as `List$Int`, every method declared with receiver `List` gets a
|
|
65
75
|
correspondingly substituted, separately-specialized copy keyed `List$Int::get`, following the
|