Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WASM support #17

Closed
newpavlov opened this issue Mar 23, 2019 · 5 comments
Closed

WASM support #17

newpavlov opened this issue Mar 23, 2019 · 5 comments

Comments

@newpavlov
Copy link
Member

Currently for wasm32-unknown-unknown target we have two features stdweb and wasm-bindgen. In future the following changes can happen:

Following those changes may cause getrandom build breakage for some users, e.g. even if we'll write stdweb = ["wasm-indgen"] in Cargo.toml it may break build for users of older stdweb versions. Thus I believe we should think about how those changes can be handled in future.

I see 3 options:

  • Publish v0.2 on each deprecation, it's the most conservative option, but will cause a great deal of churn, because we will have to do breaking releases for downstream rand crates.
  • State that both WASM features are experimental and not covered by backward compatibility promise.
  • Move both WASM back-ends to separate crates and tell WASM users to use solution from embedded source compatibility #4.

cc @koute @alexcrichton

@alexcrichton
Copy link
Collaborator

There currently aren't any plans to add more web/nodejs-specific targets AFAIK. There's been ideas of maybe we should in the past, but currently there are now plans to add more.

Ideally this crate would support the wasm32 targets without manually opting in to a feature, but requiring one isn't necessarily the end of the world.

@dhardy
Copy link
Member

dhardy commented Mar 25, 2019

The simplest option would just be to deprecate the stdweb feature at some point, and tell users that they must be using a recent enough version of stdweb and enable the wasm-bindgen feature.

I guess we should avoid releasing version 1.0 before addressing this, but don't see much point worrying about it yet.

@newpavlov
Copy link
Member Author

newpavlov commented Apr 9, 2019

As per koute/stdweb#318 stdweb is now compatible with wasm-bindgen. Though IIUC it's not build on top of it, so some users use stdweb without wasm-bindgen.

Thus the question is: should we deprecate stdweb feature or leave everything as-is?

@dhardy
Copy link
Member

dhardy commented Apr 9, 2019

I suggest we don't deprecate stdweb unless/until we have a good reason, but am not strongly opinionated on this.

Note regarding possible std integration: I think the most likely option would be not to support either of these within std, and instead use whatever mechanism were available for no_std support to provide the back-end via an external crate. In contrast, the new WASI back-end could probably be integrated (it requires only libc). [Thus it should be irrelevant to this discussion.]

@newpavlov
Copy link
Member Author

I guess we can close this issue.

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

No branches or pull requests

3 participants