a comptime fn cannot build a List, so a pure List-taking builtin is unreachable at comptime (wolf-std F-0077)

[mfwolffe]

wolf-std F-0077. Measured at wolf-lang trunk 4e316ad, both compiler rungs, --checked and --native agreeing.

A comptime fn cannot build a List:

comptime fn probe() -> int { var k = 0  k = k + 3  k }         run
comptime fn probe() -> int { let s = "hi"  s.len }             run
comptime fn probe() -> int { miss(3) else 0 }                  run
comptime fn probe() -> int { let b = List[int]()  b.len }      unsupported @resolve
comptime fn probe() -> int { str_from_utf8(List[int]()) … }    unsupported @resolve

The record carries no code and no reason string (the F-0051 silence), so this needed a bisect rather than a reading: the first three lines are what rule out the var, the str, the else and the row, and the last two are what identify the List.

The consequence is a rule, not an inconvenience: a pure builtin whose argument is a List is unreachable at comptime, whatever the sandbox thinks. s81's str_from_utf8 is the first such builtin. It carries no I13 capability and no sandbox category — D33 has nothing to say about it, exactly as intended — and it still cannot be called from a comptime fn, because a List is the only way to spell its argument.

That matters to wolf-std beyond one function. std.bytes.to_str's doc now has to read "the D33 sandbox has no objection and the engine cannot get there anyway", which is a sentence a reader has to be given, because every other signal points the other way: no capability note, no E0701, and a doc convention (§14) that spells out comptime-safety for pure members of otherwise-effectful modules. The alternative was to write "pure and comptime-safe" and be wrong in a way no test in that repository would have caught.

Two asks, in order of preference:

1. List construction and element access inside the comptime engine (s16's own scope). A comptime program that can build no container cannot do the work CTFE exists for — table generation, in particular.
2. Failing that, a NAMED refusal, so a package author learns which subset they left. This is the third caller for that half: F-0060 (json builtins refused at comptime with a bare unsupported, no diagnostic) and F-0069 (? inside a comptime fn is unsupported, and it masks the capability refusal so a D33 rejection test silently proves nothing) asked for it first. A permanent check (the sandbox) losing to a temporary one (the engine's subset), silently, is the pattern all three share.

[mfwolffe]

s88 triage: ask 2 done, ask 1 left open deliberately — and the root is not #47's.

Reproduced in a clean room at 159ce1b, both lanes, exactly as filed.

What the root actually is

The bisect in the report identified List correctly, but the mechanism is
one level below "no List at comptime":

1. List[int]() spells as a BracketApply callee, so it never reached
   resolve_callee's PathExpr arm at all — it fell out of the bottom as
   the generic "calling through this callee at comptime". That is why the
   record named nothing you wrote. (wolf run did print that string; the
   conform-run typecheck rung printed nothing at all — see below.)
2. Underneath that, the engine's value arena (ctfe::value) is
   hash-consed and immutable: Unit/Bool/Int/Float/Str/Tuple/Slice/ Struct/Fn/Type/Range/ErrTag. There is no value with identity, so there
   is nothing for List[T]() to construct and nothing for push to
   mutate. ValueKind::Slice is the closest thing and it is a frozen
   comptime slice, not a container.

So the report's rule holds exactly as stated: a pure builtin whose
argument is a List is unreachable at comptime, whatever the sandbox
thinks.

Ask 2 (named refusal) — done

Two halves, both landed in s88:

• The engine now answers with a named gap for List, Pool and
  channel heads instead of the callee-shape message:

  wolf conform-run: unsupported — `List` construction at comptime (the
  engine's values are hash-consed and immutable — scalars, `str`, tuples
  and comptime slices; no container with identity yet, so a builtin whose
  argument is a `List` is unreachable here whatever the D33 sandbox says
  about it) @41..50
  

• The F-0051 silence is fixed for every static rung. conform-run's
  typecheck, mem and wir rungs returned unsupported and printed nothing;
  only --checked and --native spoke. They all speak now, in the same
  unsupported — <construct> @lo..hi shape, on stderr. The record still
  carries no partial diagnostics — that is the conservatism ledger and it
  is about the record, not a reason for the compiler to say nothing.
  xtask lane-coverage reads these off stderr, so the residue report gets
  richer for free. This is the half F-0060 and F-0069 asked for too.

Pinned by wolf_sema/tests/ctfe_engine.rs::list_construction_at_comptime_is_a_named_gap.

Ask 1 (List at comptime) — left open, on purpose

This is an s16-scope increment, not a hole: it needs a mutable value model
inside a hash-consed arena (identity, aliasing rules, and a content hash
for a thing that changes), push/index/len on it, D33 heap accounting
for growth, and a Fold story for a site whose value is a container —
ctfe::Fold is deliberately scalar-only today. Half-doing that is worse
than not doing it, so s88 left it. No corpus file lands with this issue
for the same reason: the corpus check directives express pass/fail/run,
not unsupported, so a file could only pin the gap by pinning a refusal
we intend to remove.

Not the same root as #47 — and #47 may be stale

The sprint asked explicitly whether #47's "a comptime fn cannot call
across a module boundary" is the same root. It is not, and the measurement
is more interesting than that:

/probe/main.lu          use helper
                        comptime fn probe() -> int { helper.twice(21) }
                        fn main() -> !int { const N = probe()  print("{N}")  0 }
/probe/helper/lib.lu    //! member: true
                        pub fn twice(n: int) -> int { n + n }

Both lanes: exit(0), stdout 42. A comptime fn does resolve and
evaluate across an in-package module boundary today (resolve_callee's
namespace_member arm handles it). #47's first ask needs re-measuring —
if it is still live it is specific to the std facade, not to module
boundaries in general. Its second ask (reason strings) is the shared half,
and that is what s88 fixed above.

[mfwolffe]

s88 took the second half and left the first, deliberately.

Done: the refusal is named. The engine now names List/Pool/channel gaps instead of failing mutely, and the F-0051 silence is fixed for every static rung — conform-run's typecheck/mem/wir rungs printed nothing at all and now speak the same "unsupported — @lo..hi" line the executing rungs did. (Record unchanged; xtask lane-coverage reads these off stderr.)

Left: a comptime fn still cannot build a List. This issue's bisect named List correctly, but the mechanism is one level down: List[int]() is a BracketApply callee that never reached resolve_callee's PathExpr arm, and underneath that, the comptime value arena is hash-consed and immutable — no value with identity exists at all. Giving comptime a mutable value model, heap accounting, and a Fold story for container-valued sites is an s16-scope increment, not a fix inside this issue.

Also from s88: #47 is not the same root, and its headline may be stale — a comptime fn does resolve and evaluate across an in-package module boundary today (helper.twice(21) → 42, both lanes). Asked there for a re-measurement of the std-facade case specifically.