slices.md L51-53 'let buf: char8[1024];' doesn't compile — 'let' requires an initializer

[davidfrogley]

Summary

Web/src/docs/types/slices.md:48-53 shows fixed-size array allocation:

let buf: char8[1024];   // 1024 bytes on the stack; buf.length == 1024
let rgb: uint8[3];      // 3 bytes on the stack; rgb.length == 3

Both lines fail to compile:

error: immutable variable requires an initializer

The surrounding prose at L48 ("When you declare a variable with a fixed-size type, the compiler allocates N × sizeof(T) bytes on the stack and initialises the slice header to point at it") is the intended behavior — but it requires var, not let. The compiler has no zero-init or garbage-init path for let without an explicit initializer.

Compiler reality

Rux/Source/Sema.cpp:2060:

if (!s->init && !s->isMut) EmitError(s->location, "immutable variable requires an initializer");

The check applies to every let regardless of type — no exception for arrays. For var, the same code path passes (the !s->isMut half is false), the fixed-size array is stack-allocated with uninitialized contents, and the slice header ({data, length}) is set up correctly per L48's description.

Two ways to fix

Option A (smallest doc fix): change let to var

var buf: char8[1024];   // 1024 bytes on the stack; buf.length == 1024
var rgb: uint8[3];      // 3 bytes on the stack; rgb.length == 3

This compiles and matches the prose at L48 exactly. Storage is allocated; contents are uninitialized; the user is expected to fill them before reading. This is the C-style story and is what the language already supports.

Option B (slightly bigger): show an initialized form

If the doc wants to keep let for this example (because the rest of the page uses let for slice declarations), the example needs an initializer:

let primes = [2, 3, 5, 7, 11];   // already on the page at L62
let rgb    = [0u8, 0u8, 0u8];     // explicit element-by-element

But there's no obvious way to write a 1024-element initializer compactly — which leads into the language-gap question below.

Adjacent language-gap question (separate concern)

Even after the doc is fixed, there's no concise syntax in Rux for "immutable N-element array, all elements zero" — neither

let buf: char8[1024] = [0; 1024];   // ← not currently parseable
let rgb: uint8[3]    = [0u8; 3];

nor any equivalent. The user has three reasonable options for what should happen:

1. Garbage init — same as C / current var behavior. No language change needed; just drop the let requirement for fixed-size arrays.
2. Zero / default init — same as C static / Rust's Default. Adds a per-type "zero value" concept the language doesn't currently formalize.
3. Repeated-element initializer — [expr; N] syntax. Smallest language addition, gives the user explicit control, fits naturally next to the existing slice-literal [a, b, c] form.

This is worth its own discussion thread / RFC if the maintainer cares — it's not something the doc fix can resolve. For now I'd recommend Option A for the immediate doc cleanup, and a separate ergonomics issue if the team wants to pursue (3).