Proposal D — a maximum only: Order[max 100]

Status: accepted 2026-11-02 · The decided design and its rollout are in the Design record · Strings are char[], so a bounded string is char[max n] (decided, replacing string(max n)) · Issues and resolutions below · See the section overview for the question all four answer

The idea: a type carries only a maximum, written with the word max: Order[max 100] is at most 100 orders. There's no minimum and no range. Minimums ("at least one", "not empty") stay with validators. T[N] stays exactly N.

Why only a maximum

• The maximum is the whole reason for bounds. It lets a decoder refuse a huge length before allocating. A minimum never prevents an allocation.
• A minimum is a rule about the value, like "not empty", and that's what validators are for.
• One number can't be misread as a range. T[1..12] can read as a slice (elements 1 to 12, as in Rust and Python), as numbering, or as a count over time. T[max 12] says what it means (see Misreadings).
• The word separates "at most" from "exactly": f32[3] is exactly 3, f32[max 3] is up to 3. They don't differ only by which bracket is used.
• It leaves nothing to say about integers. u8(1..12) was ambiguous: a value from 1 to 12, a count like u8[1..12], or a call. Under D, integers take no bound, and a value range is a validator.

Shape

Every bound is T[max N], strings included. A string is an array of char (Strings as char[]), so a string of at most 64 characters is char[max 64], and exactly 2 characters is char[2]. string stays the built-in name for char[], and takes no bound itself.

History: a string's maximum was first decided as string(max 64), a form only strings had. Making strings char[] replaced it the same day, so one syntax covers everything.

const MAX_NAME: u32 = 64

/// A display name: at most 32 characters.
type AccountName = char[max 32]

/// Raw image bytes, at most 64 KiB.
type Avatar = u8[max 65536]

struct Customer {
    id: u64
    /// Never empty: the minimum is a validator.
    @validators = [NonEmpty()]
    name: AccountName
    optional email: char[max 254]
    /// Up to 10 tags of up to 32 characters each.
    tags: char[max 32][max 10]
    optional avatar: Avatar
}

/// Exactly 3 floats: the fixed array, unchanged.
struct Point {
    pos: f32[3]
}

struct Order {
    customer: Customer
    /// At least one line (a validator), at most 100 (the type).
    @validators = [NonEmpty()]
    lines: OrderLine[max 100]
    discount: union(char[max 16] u32)
    optional note: char[max MAX_NAME]
}

struct OrderLine {
    /// Exactly 8 characters: an exact length is in the type.
    sku: char[8]
    /// A month, 1 to 12: a value rule, so a validator, not a bound.
    @validators = [IntRange(min = 1, max = 12)]
    month: u8
}

/// Up to 16 rows, each with up to 8 labels of up to 20 characters.
struct Board {
    rows: char[max 20][max 8][max 16]
}

error OutOfStock {
    message = f"{item} is out of stock"
    item: char[max 64]
}

protocol Orders {
    function place(order: Order) -> u64;
    function search(query: char[max 100], limit: u32) -> Order[max 50];
    function rename(id: u64, name: AccountName) -> ();
}

NonEmpty and IntRange aren't in std today. They're shown as the validators this proposal would need.

The case for it

• Each spelling reads aloud as what it means: "order, max 100". It can't be taken for a slice, numbering, a count over time, or a call.
• "Exactly" and "at most" are distinct by a word, not by a bracket.
• Smallest concept: one number, one meaning ("never more than"), and every bound protects a decoder.
• Integers are settled: no bound syntax, so no u8(…) question.
• Changing a minimum isn't a wire change, and as a validator it isn't reported as one.

The case against

• "At least one" moves to a validator. It's common (non-empty names, lists with at least one item), and it needs validators std doesn't have yet: NonEmpty and IntRange.
• A validator's minimum is checked after decoding, not during. That's no loss for safety, since minimums don't protect allocation, but an empty list is refused one step later.
• A new word, max, inside type brackets.
• string[max 64] is an array of strings, while a bounded string is char[max 64]. Someone meaning the second may write the first (Strings as char[]).
• A minimum as a validator costs more, and isn't always enforced. See What a validator minimum costs.

What a validator minimum costs

Under D, the maximum stays in the type and is checked while decoding. Only the minimum moves to a validator. So the question is what checking a minimum in a validator costs, compared with checking it during decoding.

How validators run today (core#96):

• Rust: generated types implement Validate. On receipt they run only when the receiver sets validate_on_decode = "collect" or "first"; the default is off. When on, a struct decodes into an unchecked shadow type first, and its checks run as a separate pass over the decoded value.
• TypeScript: validators aren't generated yet (core#96, step 4d).
• A bound, by contrast, would be enforced by every decoder, always.

The cost of each minimum, per value:

What that means:

• Arrays: the same cost either way, one comparison. The validator only runs later.
• Strings: the validator pays an extra pass over each string's bytes. It's linear in the string's length: negligible for a name, measurable for long text or many strings per message. A bound would reuse the count the maximum check already took.
• Rejected values: a validator spends work decoding the rest of a message it will refuse. That's the failure path, so it matters for abuse (a peer sending many invalid messages), not for normal traffic.
• Per message: validation on decode adds the shadow-type conversion and a walk over every field that has checks. In Rust the conversion moves fields and doesn't copy them, so its cost is that walk, proportional to the number of checks.
• None of this is measured. No benchmark covers validators yet. The runtime's instruction-count benchmarks could take a case per row above.

Two ways to close the gap, if it matters:

1. Generators lower known validators into the decoder. StringBounds and a std NonEmpty have fixed meanings, so a generator could check them during decoding, reusing the character count. The schema keeps D's spelling; the cost becomes a bound's.
2. A minimum in the type after all, as A to C allow, accepting the misreadings D avoids.

The larger difference is enforcement, not speed. A validator minimum is checked only when the receiver opts in, and not at all in TypeScript today. A bound is checked by every decoder. Decided since: validators are enforced by default, and turning them off is an explicit give-up (issue 8).

Issues and resolutions

Raised 2026-11-02 while weighing D. Decided marks what the user settled; proposed is a resolution not yet agreed.

Narrowing an alias

Issue 2 is open. What narrowing an alias (AccountName, but at most 16 here) would imply:

• It needs a new syntax. A suffix after a name already means an array, so narrowing would be written some other way: AccountName(max 16), which brings back the (…) form strings just left, or an annotation on the field, @max = 16.
• The value is no longer exactly the alias. A generated checked type for AccountName (level 2) guarantees "at most 32"; it can't also guarantee "at most 16". The narrowed position becomes either an unnamed type, losing the name, or the alias plus one more check, where the type no longer states the whole limit.
• Nested aliases need a path. For type Tags = char[max 32][max 10], narrowing has to say which level: the tags or each tag.
• Docs and hover show two limits for one position: the alias's and the narrowed one.

Without narrowing, a tighter limit is a new alias: an explicit name, its own generated type, and nothing to resolve. The cost is more aliases.

Decided 2026-11-02: no suffix after such an alias where it's used. It can't be misread as narrowing, because it isn't allowed:

`Tags` is an alias of an array: change its limit in `type Tags`,
or for a list of Tags declare `type TagLists = Tags[max 5]`.

• Which aliases: those whose target takes a bound (char[], T[]). An alias of a number or a struct has no limit to narrow, so UserId[max 10] stays a list of ids.
• Alias declarations keep the suffix: type TagLists = Tags[max 5] is allowed there, or a list of Tags couldn't be written at all.
• string is exempt. With every value bounded (issue 6), a bare string is a string at the package's default maximum, and char[max N] a specific one. string[max 10] is therefore a list of 10 default strings, with nothing to misread as narrowing. Writing string[max 64] meaning 64 characters gives a list instead, which the language's type checker flags as soon as the code uses it as one string (Vec<String>, not String, in Rust), and hover says so.

Senders, by format and framing

The sender checks the value before encoding, so the check itself is the same in every format. What changes:

How a refused value is reported depends on the framing:

A framing that can't carry an error states, in its specification, how a refused reply is handled.

When this would be the right call

If bounds are there to protect decoders and nothing else, and readability without explanation matters more than writing a minimum in the type.