plum
git clone https://git.pyrossh.dev/plum
A statically typed, imperative programming language inspired by rust, python
abb8959
— Peter John
2026-07-24T07:39:14+05:30
docs: note List() explicit-fields fix in list-methods spec
docs/superpowers/specs/2026-07-24-list-methods-design.md
CHANGED
|
@@ -103,6 +103,22 @@ join<List>(self, sep: Str = ",") -> Str =
|
|
|
103
103
|
always appending a trailing separator after the last element — not a
|
|
104
104
|
regression, matching prior behavior.)
|
|
105
105
|
|
|
106
|
+
## Additional fix: `List()` must always give explicit fields
|
|
107
|
+
|
|
108
|
+
`plum-checker`'s `ClassCall` type-checking only validates whatever fields ARE
|
|
109
|
+
given, not that all of a class's fields are supplied — so `List()` (zero
|
|
110
|
+
fields) type-checks today. Codegen never initializes an unmentioned field, so
|
|
111
|
+
it's left as whatever the WASM linear memory already held there — which, for
|
|
112
|
+
memory a bump allocator has never written to before, is zero (WASM memory
|
|
113
|
+
starts zero-filled). For `size: Int` that's correctly `0`, but `head`/`tail:
|
|
114
|
+
Option[Node]` are enum-tagged, and `Option`'s declaration order (`Some` listed
|
|
115
|
+
before `None`) means `None`'s tag is very likely not `0` — so a zero-filled
|
|
116
|
+
`head`/`tail` probably decodes as a garbage `Some(...)`, not `None`. This is a
|
|
117
|
+
latent bug in the *existing* `init<List>`/`map<List>` methods (both call bare
|
|
118
|
+
`List()`), not something newly introduced. Fix: every fresh-empty-list
|
|
119
|
+
construction in this cycle — including `init`/`map`'s pre-existing bare
|
|
120
|
+
`List()` calls — becomes explicit: `List(head: None, tail: None, size: 0)`.
|
|
121
|
+
|
|
106
122
|
## Risk: generic class construction inside a generic method of another generic class
|
|
107
123
|
|
|
108
124
|
`add`'s `Node(value: v, prev: ..., next: ...)` construction is a class
|