Allow returning fixed-size tuples and arrays

[dbrgn]

It appears that returning (f32, f32, f32, f32) or [f32; 4] in a #[wasm_bindgen] function does not currently work. Would be great if fixed size arrays and tuples (maybe up to length 32) were supported.

[alexcrichton]

I think fixed-size-arrays are in theory easy enough (we'd probably pass them through allocated memory), tuples are a bit odder though. You're mostly looking for homogenous tuples, right? And both of these in JS would pop out as arrays?

[dbrgn]

Yes. In my case I'd like to pass a list of 2D-coordinates to JS. Using a fixed size array would work fine too of course.

[David-OConnor]

Would love to see this as well, for both arrays and tuples. The output for either could be a JS array.

[rhysd]

This would be great.

In my use case, I wanted to return RGB value as 3 elements tuple or array of u8. However, they are not yet supported so I needed to create a struct like

#[wasm_bindgen]
pub struct Rgb { pub r: u8, pub g: u8, pub b: u8 }

But it is not so efficient since in JavaScript, accessing each field causes interaction between wasm and JS.

console.log(color.r, color.g, color.b);

For this use case, I could finally use 0xrrggbb format of u32 values for RGB values. But it's a solution only for this use case.

---

I also think mapping tuples to JS array is fine and reasonable. TypeScript supports tuples and actually it is transpiled into array.

https://www.typescriptlang.org/docs/handbook/basic-types.html

[RReverser]

As another use-case, I think tuples support could improve interfaces for js-sys iterators too.

In particular, .entries() on Map / Set / Array could produce an iterator over tuples of (JsValue, JsValue) right away instead of users having to repeat same boilerplate with JsArray + Reflect::get_u32(..., 0) + Reflect::get_u32(..., 1) to extract key and value on each iteration.

[RReverser]

Just an update - I imagine this might become easier these days (or, at least, soon) by leveraging multi-value Wasm feature.

[josephrocca]

In case it's relevant to the discussion (e.g. RE wasm-bindgen backwards compatibility concerns, if there are any), and in case others are unaware, JS will probably get tuples in the next couple of years. The tc39 proposal repo has 1.4k stars (very high - up there with the decorators proposal) and the proposal is at stage 2 as of writing.

@josephrocca, Tuples refer to Rust tuples, Wasm multi-value tuples return JavaScript arrays, and it would make the most sense to target the Wasm feature so that some cases won't need a wasm-bindgen shim at all.

[ForkKILLET]

Are we waiting for the TC39 tuple proposal?

[stegaBOB]

@alexcrichton

I think fixed-size-arrays are in theory easy enough (we'd probably pass them through allocated memory)

is this still the case? I'm not too familiar with the internals of wasm_bindgen (yet), but I'd be interested in taking a stab at this!

[daxpedda]

@stegaBOB I'm not entirely sure how easy or hard to implement this really is, but I'm happy to review a PR!

[stegaBOB]

@daxpedda I think we're pretty close to getting something that's working & ready for a review! As of now we're focused on getting fixed size arrays working only for compiling w/ multi-value. Would proceeding like that and throwing a runtime error on wasm-bindgen-cli if fixed size arrays exist and multi value is off be an acceptable change?