Cross-repo review request: typed-wasm proposal 0002 (typedwasm.access-sites carrier) #449

Context

hyperpolymath/typed-wasm has filed proposal 0002 — the access-site carrier section (typedwasm.access-sites) that completes L2 enforcement on emitted wasm by mapping i32.load offset=N back to (region_id, field_id).

This is the companion to proposal 0001 (which affinescript already reviewed in #402). 0002 is the spec response to typed-wasm#78 (access-site carrier gap discovered during 0001's codec work).

Per 0002's §Coordination with downstream producers (line 252) and §Acceptance criteria (line 384), this proposal requires explicit review-and-sign-off from affinescript maintainers before promotion from [draft] to [accepted].

What we're asking

Please review the proposal as it relates to affinescript's wasm emitter (lib/codegen.ml + lib/tw_*.ml). The proposal proposes Encoding B (LEB128 per field) at v1, with per-instruction (func_idx, byte_offset, region_id, field_id) records emitted after any optimisation passes.

Specifically, please assess:

1. Post-optimisation emission constraint. AffineScript's codegen (lib/codegen.ml) currently emits typedwasm.ownership at codegen.ml:2778. Does affinescript run wasm-opt / binaryen as part of its build pipeline today? If not, this is trivially satisfied; if yes, the access-site carrier needs a hook between optimisation and final emission.

2. byte_offset stability. Encoding B records byte_offset of each typed access within the function body. Are affinescript's offsets stable at section-build time, or is there a rewrite stage post-build that would invalidate them?

3. Typed-vs-arbitrary load distinction. The proposal defines typed accesses as loads/stores emitted as part of typed region access (not arbitrary memory ops). Does affinescript's codegen distinguish typed-region loads from arbitrary memory loads at emission, or is this a new producer-side instrumentation task?

4. Encoding cost. Per the prototype measurement in typed-wasm#78's second comment, Encoding B is ~5 B/access (~43% overhead vs the bare i32.load). Acceptable for affinescript-emitted modules?

5. Carrier-codec sharing. Note: the planned affinescript#444 Tw_section.{Encode,Decode} refactor would let the access-site carrier slot in cleanly alongside typedwasm.ownership and (eventually) typedwasm.regions. Worth landing tw: extract Tw_section.encode — deduplicate build_section before proposal 0001 lands two more sections #444 before this proposal's codegen work begins.

6. verify_region_binding interaction. Acceptance criterion 4 lands the verify_region_binding pass (omitted from typed-wasm PR fix(build): format js/dune #77 pending this proposal). Does affinescript need any change to how it currently emits typedwasm.ownership to accommodate the L2 round-trip, or is the change wholly on the typed-wasm verifier side?

Process

This is the paired-review pattern that worked for proposal 0001 (this repo's #402 + ephapax#165). Same shape:

• File this issue + the ephapax sibling.
• Maintainers post a structured review comment ("covered / gap / not-emitted-yet" per question).
• When both producers greenlight, proposal 0002 promotes [draft] → [accepted] and the codec + verifier work in typed-wasm proceeds.

References

• Proposal 0002 (full text): https://github.com/hyperpolymath/typed-wasm/blob/main/docs/proposals/0002-access-site-carrier.adoc
• Tracks issue: Access-site carrier: how does the post-codegen verifier map (i32.load offset=N) back to (region_id, field_id)? typed-wasm#78
• Companion review for proposal 0001 (this repo): Review request: typed-wasm carrier-section proposal for L2–L6 / L15 enforcement (typed-wasm#76) #402
• Companion review for proposal 0001 (ephapax): Review request: typed-wasm carrier-section proposal for L2–L6 / L15 enforcement (typed-wasm#76) ephapax#165
• Ephapax sibling of this issue: (to be filed in parallel)
• Related: tw: extract Tw_section.encode — deduplicate build_section before proposal 0001 lands two more sections #444 (Tw_section.{Encode,Decode} refactor — prep-work that simplifies ci: Bump actions/github-script from 7.0.1 to 8.0.0 #5 above)