Repository navigation
Bounds written on types: T[a..b], string[..n] #98
Description
Allow bounds written directly on a type: T[1..10], T[..10], string[..64] (syntax open).
How this differs from validators
| Bounds on the type | Validators | |
|---|---|---|
| What they express | the shape of the data | rules about values |
| Effect on generated types | can change them ([T; N], a fixed-capacity string) |
none |
| When they're enforced | always, while decoding | when validate() runs, or on decode if opted in |
| Safety | the decoder can refuse an oversized length before allocating | only after the value is fully decoded |
| Wire and size | a fixed T[N] may omit the length prefix; size.rs can compute sizes |
no effect |
| Changing them later | wire-relevant: tightening breaks old senders, loosening breaks old receivers | a behaviour change only |
The main reason to have these is the maximum: it protects decoders from huge allocations, which a validator can't do. Minimums can live in either place.
Points to settle
- Unit for
stringbounds: UTF-8 bytes, because the bound exists for decoder safety and allocation. Validators count Unicode scalar values (Validators declare the types they apply to #97). These are different rules, and the docs should say so. - Contradictions:
string[..10]combined withStringBounds(min_chars = 20)can never pass, so core should reject it at build. Optionally, warn when a validator only repeats a bound. - Aliases:
type AccountName = string[1..32]carries the bound in its type, and validators on the alias add rules on top. - Fixed-size representation: a bounded
stringlets a generator emit a fixed-capacity, non-heap string if it chooses to. That is the generator's decision, not a schema orcomline.tomlsetting. - Schema evolution: whatever compares schema versions should treat a bound change as wire-relevant.
Depends on
- Keep type structure in the compiled schema (fixed array length, f32/f64, unions) #95 (the IR must keep array shape before it can keep bounds)
Activity
Merge pull request #200 from ComlineProject/feat/bounds-in-shape-hash
Kinflou commentedon Nov 9, 2026
Complete: steps 1–10 are merged across core (#191–#196, #200), runtime#78, generation#110/#112/#114–#116, comline-rust#100/#101/#104, comline-typescript#122/#124–#127, cli#130, language-server#97 and playground#111. The one leftover, checking worst-case encoded sizes against the configured frame limits, is tracked in #202.