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

[hyperpolymath]

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 ephapax already reviewed in #165). 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 ephapax maintainers before promotion from [draft] to [accepted].

What we're asking

Please review the proposal as it relates to ephapax's wasm emitter (src/ephapax-wasm/). 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 (e.g. wasm-opt).

Specifically, please assess:

1. Post-optimisation emission constraint. Ephapax currently emits typedwasm.ownership from src/ephapax-wasm/src/lib.rs:1277. Will the access-site carrier need to land downstream of any binaryen / wasm-opt pass in ephapax's pipeline, or does ephapax skip that step today? If skipped, this proposal's "emit AFTER all such passes" requirement is trivially satisfied; if not, ephapax 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. Does ephapax's codegen produce stable offsets at the point of emission (no further rewrites after section build), or is there a rewrite stage that would invalidate offsets?

3. Source-language scope. Per the proposal, typed accesses are defined as i32.load offset=N / i32.store offset=N instructions emitted as part of a typed region access (not arbitrary memory ops). Does ephapax's codegen distinguish typed-region loads from arbitrary memory loads at emission time? If not, this is a producer-side work item.

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 ephapax-emitted modules?

5. verify_region_binding interaction. The proposal's acceptance criterion 4 lands the verify_region_binding pass (omitted from typed-wasm PR V2 grammar extern typecheck #77 pending this proposal). Does ephapax need any change to how it currently emits typedwasm.ownership to accommodate the verifier's 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 #165 + affinescript#402). Same shape:

• File this issue + the affinescript 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) #165
• Companion review for proposal 0001 (affinescript): Review request: typed-wasm carrier-section proposal for L2–L6 / L15 enforcement (typed-wasm#76) affinescript#402
• Affinescript sibling of this issue: (to be filed in parallel)

[hyperpolymath]

Closing — proposal 0002 reached [accepted] via typed-wasm#115 and was promoted to ADR-0003. Ephapax-side codegen access-sites follow-up still owed (file at owner discretion).