[]mut T arguments: collection->mutable-slice coercion is missing (blocks #379 buf_out)

[ehartford]

Summary

With cannot construct a []mut T (mutable slice) argument from a collection. This blocks #379's buf_out fact (memset/explicit_bzero need a []mut u8). Deep-dive below; no code/spec change made pending a scope decision.

Root-cause analysis (deep dive)

[]mut T is a real, live type — TY_SLICE whose d1 field is the mutability flag. The argument compatibility check is correct and strict:

• src/Sema.w:4426-4429: if exp_k==TY_SLICE and act_k==TY_SLICE: if d1(exp)!=0 and d1(act)==0: return 0 — a []mut parameter demands an actual []mut value; []T does not satisfy it.

The gap is that nothing produces a []mut T value:

• Slice-creation expressions (a[..], a[0..3]) always build an immutable slice — they emit TY_SLICE with d1=0 regardless of source mutability or expected type (e.g. src/SemaCheck.w:414, range/subscript typing).
• split_at_mut returns the Vec-specific VecRange[T], not []mut T (src/SemaCheck.w:14790-14811; mutable Vec access is .set()/.get() on VecRange).
• A bare collection does not coerce: passing var a: [3]u8 to a []mut u8 parameter gives wrong argument type (it also fails for []u8 — only a[..]/a[0..3] coerce, and only to immutable).

Spec intent: this is a compiler bug, not a stale spec

§4.8 (spec lines 2083-2086) explicitly promises the coercion:

"in parameter position, []T and []mut T follow §3.8's borrow mode: the caller's collection coerces to the slice view … for []mut T, the exclusive borrow ends when the callee returns."

So []mut T is the intended model and VecRange is a separate Vec convenience, not a replacement. The compiler is simply missing the collection→[]mut T coercion. Per AGENTS.md ("spec says X works, compiler disagrees ⇒ compiler bug"), this is a bug to fix.

Proposed design

Produce a mutable slice (TY_SLICE d1=1) when, and only when, (a) the expected parameter type is []mut T, (b) the source place is mutable (var binding / mutable field / mutable receiver), and (c) §21.1 exclusivity holds (no overlapping live &T/[]T/[]mut T view of the same place). Touch points:

1. Slice-creation typing (range/subscript expr → TY_SLICE): thread expected-mutability + source-mutability to set d1. Today it hardcodes d1=0.
2. Call-argument coercion: accept a mutable collection / a[..] over a mutable source as []mut T (mirror of the existing []T array→slice coercion).
3. Borrow/exclusivity checker (§21.1): register the exclusive borrow for the argument's lifetime — invalidate overlapping &T/[]T views until the callee returns. This is the subtle part.
4. MIR/codegen: none expected — a mutable slice has the same (ptr,len) fat-pointer ABI as an immutable one; mutability is compile-time only. (The buf_out wrapper already uses &raw mut s[0], validated to compile.)

Size estimate

Medium. The slice machinery + fat-pointer ABI already work end-to-end for immutable slices, so (1) and (2) are small-to-medium. The risk and most of the effort concentrate in (3) — getting §21.1 exclusivity right for the slice argument (overlap invalidation, NLL end-of-borrow at callee return). Roughly comparable to the buf_in work but reaching into the borrow checker rather than binding-gen. Recommend a dedicated session with adversarial borrow-checker tests.

Once this lands

#379 buf_out is then trivial: add the curated entries (memset out:0:2, explicit_bzero out:0:1, …) to ci_buf_is_mut/ci_buf_count in src/CImport.w. The generator already emits the []mut u8 + &raw mut wrapper; only the overlay config and tests remain.

Status: analysis + design only. Awaiting maintainer decision on whether to fix the coercion (Option A) before resuming #379 buf_out. No []mut T semantics changed.

[ehartford]

Correction: reconcile the contradiction before designing (intent was not settled)

My initial analysis proved the mechanics in code but inferred design intent from spec text, and left one fact unreconciled: split_at_mut returns VecRange, not []mut T. That premise is load-bearing — it decides the shape of the fix — so I settled it from code. The earlier "emit d1=1 from slice-creation" recommendation is withdrawn pending the decision below.

Code evidence

1. []mut T has no producer and zero usages. grep "[]mut" across lib/std/, examples/, test/ returns 0 files. The only TY_SLICE sites that set the mutability flag (d1) read it from a written type annotation (SemaCheck.w:434, 12674, 13253 → get_data1(typeNode)); every value-producing site — slice/range/subscript expressions — hardcodes d1=0 (SemaCheck.w:8742, MirLower.w:1603). So []mut T is a type you can write but the compiler never constructs, and the compat check (Sema.w:4427) then makes any []mut T parameter unsatisfiable.

2. VecRange is the working mutable model. VecRange[T] = { data_ptr, offset, len } (CodegenDispatch.w:8057), produced by .range() / split_at_mut, with get/set/len/split_at_mut intrinsics, working on both Vec and fixed arrays: var xs=[10,20,30,40]; xs[1..4].split_at_mut(1); r.set(0,99) mutates successfully. Mutation never flows through []mut T.

3. The spec's own split_at_mut example comments // left: []mut T but the implementation returns VecRange. So the spec↔impl divergence is real and centered exactly on the contested point.

Conclusion + the decision (maintainer's call — language/spec, not mine)

The code says VecRange is the de-facto mutable currency and §4.8's []mut T promise is stale. Two ways to make it consistent:

• (A) Bless VecRange (matches the implementation). Update §4.8/§4.8a so the mutable-slice currency is VecRange[T] (and split_at_mut officially returns it). Then buf_out is VecRange-shaped: the generated memset/explicit_bzero wrapper takes VecRange[u8] and passes (data_ptr + offset, len) to C. No borrow-checker change; uses the existing, working mutable model. This is the smaller, lower-risk path and is consistent with how all current mutable code is written.
• (B) Realize []mut T (matches the spec text). Make value-producing slice expressions emit d1=1 under a mutable source + expected []mut T, and wire §21.1 exclusivity for it (the risky part I flagged). Larger, and it introduces a second mutable-view mechanism alongside VecRange unless split_at_mut is also migrated to return []mut T — i.e. it implies reworking the existing mutable model, not just adding a coercion.

Recommendation: (A). It's what the language actually does today, it's lower risk (no borrow-checker surgery), and VecRange already carries the (ptr, len) shape buf_out needs.

Stopping here. No []mut T / VecRange / spec semantics changed. Once you pick (A) or (B), I'll land the chosen mutable-slice work as its own unit with adversarial exclusivity/aliasing tests, verify, and only then add the buf_out overlay entries to #379.

[ehartford]

Correction #2: Option A (VecRange-shaped buf_out) is not viable — and []mut T is NOT stale

Attempting to implement Option A surfaced facts that reverse my prior "VecRange is the model, §4.8 is stale" conclusion. Reporting before any code/spec change.

Option A is impossible

• VecRange is unspellable as a type. fn memset(s: VecRange[u8], ...) → error: unknown type: VecRange. It is compiler-internal (self.syms.vecrange), not a user-facing type name. No function anywhere takes a VecRange parameter (grep across lib/std, src, test, examples: zero).
• A mutable view cannot cross a function boundary today. Checked every mechanism: mut param: Vec[u8] moves the Vec (use of moved value after the call — ownership transfer, not a borrow); mut self is method-only and type-specific; VecRange is in-scope only. None expresses "mutate the caller's byte buffer in place via a free wrapper function."

Refined reconciliation (corrects the earlier verdict)

VecRange and []mut T are not competing models — they serve different roles:

• VecRange = in-scope mutable view (local, via with/range/split_at_mut). Not passable to functions.
• []mut T = the spec's intended cross-function mutable-slice parameter (§4.8: "the exclusive borrow ends when the callee returns" — that sentence is specifically about parameter passing).

So the split_at_mut → VecRange fact does not prove §4.8 is stale. []mut T is the designed-but-unimplemented mechanism for exactly the function-boundary case buf_out needs. My earlier "fix the §4.8 promise / it's stale" was wrong: the promise reflects real, unmet intent — a genuine compiler gap, not decoration. I withdraw the recommendation to edit §4.8.

Consequence for #379 buf_out

buf_out's clean surface (memset(buf, c) mutating a caller buffer) genuinely requires []mut T as a real cross-function mutable slice. That is the language-design call the maintainer has reserved to decide on its own merits — it is not a side effect of #379, and there is no viable in-#379 surface that avoids it (VecRange can't be a param; mut Vec moves; raw stays raw).

Therefore buf_out cannot ship within #379 without that separate []mut T decision. Recommended recording: memset/explicit_bzero stay raw (already the case — no regression); #379 buf_out is blocked on the []mut T mechanism, tracked here. cstr_in + nullable_ptr + buf_in are shipped and complete.

No code or spec changed. Awaiting your call on how to record buf_out (blocked-on-[]mut T vs out-of-scope), and the separate []mut T decision in your own time.

[ehartford]

Correction #3 (definitive, fully tested): buf_out is NOT impossible

My "no mutable buffer can cross a function boundary" rested on the single free-mut Vec move test plus an assumed, never-run Arena in-place behavior. Run, the Arena-style free mut param also moves. In-place mutation across a call is a mut self (method) property, not a free-mut param one. Full tested matrix:

Mechanism	Result	Evidence
free mut param (Vec, struct)	moves	use of moved value after call
mut self method	in-place, usable after	c.bump()×2 → 7; mut self method memset via &raw mut self.data[0] → 65
move-in / return f(Vec[u8]) -> Vec[u8]	works	xs = memset_vec(xs, 65) → 65, 65
[]mut T free param	unimplemented (no producer)	—
VecRange param	unspellable (unknown type)	—
call-site mut xs / &mut xs	parse error	—

Reconciliation

• The §4.8 []mut T parameter promise is genuinely unmet (a real gap) — not stale, but also not the only way to cross a boundary mutably.
• A Vec-backed buf_out ships today via move-in/return or a mut self method. The clean in-place free-function slice surface (memset(slice, c)) still needs []mut T.

The (narrowed) decision

• (A) Ship a Vec-backed buf_out now — generate memset/explicit_bzero as move-in/return (fn memset(buf: Vec[u8], c) -> Vec[u8]). Works today, safe. Cost: Vec-only (no arrays/sub-ranges), move-in/move-out ergonomics (caller rebinds), and it's a real c_import modeling choice (remodeling a C in-place op as consume→return).
• (B) Hold buf_out for []mut T — the clean in-place free-function surface. memset stays raw meanwhile (no regression). []mut T is the separate language call.

No code/spec changed. The "impossible" verdict is withdrawn; buf_out is a surface-choice decision, not a hard blocker.

[ehartford]

Final corner closed: matrix is exhaustive; buf_out held (downstream of []mut T)

Tested the one remaining corner — a free-function mutable-reference parameter:

• fn f(buf: &mut Vec[u8]) → rejected (&mut is not a valid parameter type; consistent with "no safe &mut T").
• &raw mut buf[0] through a shared &Vec param → rejected (no mutable raw pointer from a shared ref).

So there is no free-function mutable-borrow parameter; in-place mutation across a call is method-only (mut self). The mechanism matrix is now exhaustive.

Decision: HOLD buf_out (this is not the deferral pattern)

Every today-viable buf_out surface is worse than the raw fallback for an in-place C buffer op:

• move-in/return (fn memset(buf: Vec[u8]) -> Vec[u8]) misrepresents memset (a mutation, not consume→return), forces caller rebind, Vec-only.
• mut self method needs a synthetic receiver type and turns a free C function into a method.

The overlay exists to provide better surfaces; auto-generating either would degrade the API. memset/explicit_bzero stay raw (callable under unsafe today — no regression).

buf_out is correctly downstream of the []mut T language decision, not blocked-in-limbo. This issue (#604) is the tracker for the cross-function mutable-slice mechanism ([]mut T realized as a real parameter, per §4.8's intent). It has value beyond buf_out; when it lands, buf_out falls out for free with the clean memset(buf, c) in-place surface. Until then, raw is the right surface.

The "impossible" verdict is fully withdrawn; this is a surface-quality choice, settled.

[ehartford]

Ruling: Option A, staged — realize []mut T per spec §4.8, parameter-position first.

Judged against the mission and the spec taken as a whole:

• §4.8 already promises mutable slices. Blessing VecRange would regress the surface to an implementation artifact — and the artifact was verified to snapshot (data, offset, len) with no runtime validation, i.e. the same hazard class as a slice. Option B buys nothing.
• §2.5's runtime-fact model deliberately covers owners (reset-on-move) and handles (per-slot generation) but not borrows — the borrow row is ephemerality + §21.1 Rule 1 view-liveness. Parameter-position []mut T extends that existing, load-bearing machinery; it does not need new invention.
• The mission test — does this make the user state something the compiler already knows? — condemns routing callers through a named wrapper when fn f(buf: []mut u8) is what they mean.

Staging (from the decision brief):

1. Parameter position first: collection→[]mut T coercion at call sites from mutable places, d1=1 slice creation, call-local §21.1 exclusivity (the view is ephemeral; the source is inaccessible for the call's duration). Codegen unchanged — same fat-pointer ABI as []T.
2. This unblocks Curated libc contract overlay for c_import modeled surfaces #379 buf_out (memset/explicit_bzero) immediately.
3. Local-binding and return-position []mut T follow as separate increments under the same §21.1 rules, each with its own gates.

Implementation proceeds under this ruling; VecRange stays internal.

[ehartford]

Spec tension flagged during campaign planning (needs Eric's ruling before stage 3): §4.8a says slices "cannot be stored in structs or returned from functions", but §21.1 Rule 6 defines returned-view origin tracking, and this issue's staged ruling lists RETURN position as stage 3. Provisional plan: ship stage 2 (local bindings — permitted by both sections) and do not start stage 3 or amend the spec until the contradiction is ruled. Options: (a) Rule 6 governs, amend §4.8a's blanket sentence; (b) §4.8a stands, stage 3 is dropped and Rule 6 is &T-only.

[ehartford]

Ruling on the §4.8a tension (WWED, mission-derived): Rule 6 governs. Spec amended (§4.8a now: slices can't be stored in structs — handles are for persistence — and RETURNS are checked by §21.1 Rule 6 origin tracking). Stage 3 (return-position []mut T) is unblocked and stays on the roadmap after stage 2 (locals).

[ehartford]

Stage 2 (local bindings) scoping — ergonomic core verified working, but exclusivity is unenforced; deferred as real borrow-checker work.

Prototyped stage 2 (widen the in_param_type_position choke point to local binding annotations + make arr[..] yield d1=1 when expected is []mut and the source place is mutable). Verified: let s: []mut i32 = a[..]; s[0] = 9 compiles and the write reaches a (prints 9); []mut returns/fields stay rejected; let-arrays are element-mutable so []mut off a let array is legitimate.

Blocker: §4.8a exclusivity is not enforced and cannot be cheaply added. var a; let s: []mut i32 = a[..]; a[0]=100; s[1]=200 and two overlapping []mut slices of the same source both check clean today — the aliasing §4.8a forbids ('while a []mut T is live … the range may not be read or written through any other path; a second overlapping []mut T is rejected'). Root cause: slices have NO borrow-tracking at all right now (even let s = a[0..2]; a[0]=9 on an immutable slice isn't tracked). Stage 1's exclusivity was call-LOCAL (single point); a binding needs the exclusive borrow tracked across the binding's NLL lifetime — genuinely new machinery (register the slice as an exclusive view of the source place; reject source read/write and second views while live; release at last use). Shipping the ergonomic core without it would reintroduce the mutable-aliasing hole the #600/#605/#606 work just closed, so it's not shippable as-is. Stage 2 = a focused borrow-checker cycle, not a quick win. Reverted to keep the tree clean.