lang 2.4: lock protocol-pack access semantics (interface-only)

Design decision: a protocol-constrained pack element is viewed THROUGH the
constraint protocol — only the protocol's interface (its methods, and the
projections xs.T / xs.value) is accessible, not arbitrary concrete members,
exactly like a constrained generic `T: Show`. So `xs[i].v` (a field on the
concrete IntBox, not declared on Show) is an error; the constraint is enforced
and bounds the body regardless of the concrete arg types at a call site.

The previous example 191 demonstrated `xs[i].v` — which only compiled because
the constraint is not yet enforced. Trimmed it to the protocol-agnostic part
that's correct today (per-shape binding + comptime `xs.len` across arities /
heterogeneous shapes); protocol-interface access + projection are the remaining
2.4 work. specs.md records the access rule.

examples/191-protocol-pack.sx

@@ -1,13 +1,17 @@
-// Feature 1 — heterogeneous protocol-constrained variadic pack.
+// Feature 1 — heterogeneous protocol-constrained variadic pack (binding).
 //
 // `..xs: Show` (no `[]`, no `$`) is a pack, not a slice: each call site
-// monomorphizes with the concrete per-position arg types, and `xs[i]` IS the
-// concrete element (comptime substitution, Decision 1) — so its own fields /
-// methods dispatch statically. `xs.len` is a comptime constant. Elements may
-// be DIFFERENT concrete types as long as each conforms to the protocol.
+// monomorphizes with the concrete per-position arg types (Decision 1 — a pack
+// is a comptime mechanism, no runtime pack value), and `xs.len` is a comptime
+// constant. Arity and element types vary per call; each call is a distinct
+// specialization.
 //
-// (Conformance checking and projection `xs.T` / `xs.value` are still to come;
-// this locks in the per-shape binding + concrete-element access.)
+// DESIGN (locked): a pack element is viewed THROUGH the protocol — only the
+// protocol's own interface (its methods, and the projections `xs.T` / `xs.value`)
+// is accessible, NOT arbitrary concrete members. So `xs[i].get()` / `xs.T` are
+// the intended interface; `xs[i].v` (a field on the concrete IntBox, not part
+// of `Show`) is an error. Those are still being implemented — this example
+// locks in only the binding + comptime `xs.len`, the protocol-agnostic part.
 
 #import "modules/std.sx";
 
@@ -24,23 +28,12 @@ howmany :: (..xs: Show) -> s64 {
     return xs.len;
 }
 
-sum2 :: (..xs: Show) -> s64 {
-    return xs[0].v + xs[1].v;
-}
-
-describe :: (..xs: Show) -> void {
-    // Heterogeneous: xs[0] is an IntBox, xs[1] a StrBox.
-    print("describe len={} first={} second={}\n", xs.len, xs[0].v, xs[1].s);
-}
-
 main :: () -> s32 {
     a := IntBox.{ v = 42 };
     b := IntBox.{ v = 7 };
-    print("count0={}\n", howmany());          // N=0 pack
-    print("count2={}\n", howmany(a, b));       // N=2
-    print("sum={}\n", sum2(a, b));             // concrete field access via pack
-
     c := StrBox.{ s = "cool" };
-    describe(a, c);                            // heterogeneous IntBox + StrBox
+    print("n0={}\n", howmany());            // empty pack
+    print("n2={}\n", howmany(a, b));         // two elements
+    print("n3={}\n", howmany(a, b, c));      // heterogeneous: IntBox, IntBox, StrBox
     0;
 }

specs.md

@@ -990,6 +990,16 @@ A pack is **not a runtime value** — it lowers to N typed positional parameters
 below; using the pack name where a runtime value is required is an error (see
 "Pack as value").
 
+**Element access is through the protocol, not the concrete type.** Although the
+pack monomorphizes per call shape and each element has a known concrete type,
+`xs[i]` is viewed **through the constraint protocol**: only the protocol's own
+interface (its methods, and the projections `xs.T` / `xs.value`) is accessible.
+Reaching a concrete member that isn't part of the protocol — e.g. `xs[i].v`
+where `v` is a field of the concrete `IntBox` but not declared on `Show` — is an
+error, exactly as it would be for a constrained generic `T: Show`. The protocol
+constraint is enforced (each trailing arg must conform) and bounds what the body
+may do, regardless of the concrete arg types at any particular call site.
+
 #### Pack operations
 
 | Use | Spelling | Meaning |

tests/expected/191-protocol-pack.txt

@@ -1,4 +1,3 @@
-count0=0
-count2=2
-sum=49
-describe len=2 first=42 second=cool
+n0=0
+n2=2
+n3=3