feat(jsvalue) Add JsValue.ptr to retrieve internal idx value

[Hywan]

I'm trying to solve #2231, and the first immediate step is to make JsValue.idx visible to the world. There is nothing particularly dangerous to allow that.

[alexcrichton]

Personally I have always wanted to avoid this in wasm-bindgen if possible. This is a low-level implementation detail which is extremely hard to get right.

That being said it's been a long time since I originally felt that. I don't really mind that much any more, although I continue to feel that using this is highly likely to get yourself shot in the foot.

If this is added, though, then I think it should be done "officially". For example if there's a getter there should also be a constructor. There should ideally be more than a sentence of documentation about what the index is and how to use it. Additionally I think it would be good to mention this in the book about perhaps the design rationale behind the indices and how things work today.

[Hywan]

I agree with everything. I'm not comfortable exposing idx but at some point it might be useful.

If this is added, though, then I think it should be done "officially". For example if there's a getter there should also be a constructor

This is dangerous to provide a constructor. The getter function should already be unsafe I guess now that I'm thinking about it. With a constructor, the user must guarantee that another JsValue with the same idx value does not exist.

I've a relatively stupid question: Is idx the ptr object property we see from JavaScript? If yes, it could be changed from JavaScript too, which is annoying now. Not sure how it syncs.

[alexcrichton]

No the idx and ptr are not the same thing. The idx is an index into the private list of JS objects that the wasm holds a reference to, and the ptr is a pointer into linear memory for Rust-owned objects.

I don't think the getter needs to be unsafe, along the lines of as_raw_fd, but the constructor would be unsafe. This probably would also want an into_idx or similar as well.

[Hywan]

Closing in favor of #3088.