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

Expose BigInt bindings #1087

Closed
RReverser opened this issue Dec 6, 2018 · 15 comments
Closed

Expose BigInt bindings #1087

RReverser opened this issue Dec 6, 2018 · 15 comments

Comments

@RReverser
Copy link
Member

PR #188 a while back added mapping of {u,i}64 to BigInts for custom bindings, but there is still no implementations of From<{u,i}64> for JsValue or raw BigInt bindings which makes their construction a bit cumbersome in generic contexts.

@RReverser
Copy link
Member Author

RReverser commented Dec 6, 2018

Looking into this further, I see that some other types that are castable when creating manual bindings, are not supported with explicit conversion to JsValue.

I wonder if it would make sense to provide a blanket implementation of From for JsValue for any type supported by wasm-bindgen itself (via : JsCast constraint or something like it)?

@alexcrichton
Copy link
Contributor

We've previously decided that any phase 4 proposals can be added to js-sys, so once it's there we're good to go!

@RReverser
Copy link
Member Author

Ah I see. And how about a blanket From implementation for any types supported by wasm-bindgen itself as suggested above?

@alexcrichton
Copy link
Contributor

I think we currently have that? Although we may be missing a few by accident!

@RReverser
Copy link
Member Author

That's what I'm trying to say - BigInt seems to be one of these, if I understand correctly. I mean, it's possible to create custom function with #[wasm_bindgen] attribute that accepts/returns u64 and that would translate to BigInt on JS side, but it's not possible to similarly convert u64 to JsValue directly.

@alexcrichton
Copy link
Contributor

Oh sure yeah makes sense, and seems fine by me to add!

@alexcrichton
Copy link
Contributor

We decided awhile back that we'd bind stage 4+ proposals, and it looks like this is currently stage 3 so I'm going to go ahead and close this.

@RReverser
Copy link
Member Author

Nooo, I'm working on it in a branch, there is just a bunch of different changes needed. ;(

@alexcrichton
Copy link
Contributor

Oh that's still fine! I just figured we didn't need a tracking issue for something that's not quite ready yet, but there can always be a crate on crates.io that we pull in later

@RReverser
Copy link
Member Author

Wouldn't it be a bit inconsistent that wasm-bindgen already internally relies on BigInt for u64/i64 support, but doesn't expose explicit bindings to it?

This was the main motivation for this issue.

@alexcrichton
Copy link
Contributor

It only relies on it in an experimental fashion because it's the only way to work with some of those types.

@recmo
Copy link

recmo commented Mar 10, 2020

BigInt has since moved to stage 4: https://github.com/tc39/proposals/blob/master/finished-proposals.md

@trevyn
Copy link
Contributor

trevyn commented Aug 27, 2021

the trait `From<i64>` is not implemented for `JsValue`

@RReverser I just hit this, and it looks like BigInt is now good to go. Did you have something that works, or shall I take a crack at it?

@RReverser
Copy link
Member Author

or shall I take a crack at it?

Feel free to do it, I stopped my work back then when this feature request was closed due to API being experimental.

@trevyn
Copy link
Contributor

trevyn commented Aug 28, 2021

These bindings are present and working in #2629.

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

4 participants