Skip to content

feat: add wasip3 behind flag#127

Closed
ricochet wants to merge 2 commits intobytecodealliance:mainfrom
ricochet:worktree-p3
Closed

feat: add wasip3 behind flag#127
ricochet wants to merge 2 commits intobytecodealliance:mainfrom
ricochet:worktree-p3

Conversation

@ricochet
Copy link
Copy Markdown

@ricochet ricochet commented Apr 7, 2026

No description provided.

ricochet added 2 commits April 7, 2026 09:05
Now when wasm32-wasip3 lands, users can compile with just
`--target wasm32-wasip3`

The cfg alias activates the p3 path AND the wasip3 deps are auto-pulled.
@ricochet
Copy link
Copy Markdown
Author

ricochet commented Apr 7, 2026

I'm going to close this in favor of someone else having the opportunity to start fresh on finding the right abstraction. The actual work is figuring out where the seams should be. Some concrete questions to investigate:

  • What does AsyncRead/AsyncWrite look like as a single trait that both p2 streams and p3 streams implement?
  • Can block_on and the reactor be unified? p3 doesn't need a reactor, but the public API of wstd::runtime could be the same, perhaps a no-op shim under p3?
  • The #[http_server] macro is the hardest case because the WASI export traits are genuinely different. Possible approaches: a sealed HttpServer trait that both versions implement, with the macro generating the impl.
  • Today the diff has BodyInner::Incoming and BodyInner::P3Stream as parallel variants. A single internal trait BodyBackend with two implementations would be better.

Any version-specific code should be at the bottom of the abstraction stack, not woven through.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant