proposal: syscall/js: allow `[]float32` or other typed arrays to pass to `js.ValueOf`

[hajimehoshi]

This would be useful for WebGL functions: for example, uniformMatrix4fv accepts Float32Array at the third argument.

(This issue is copied from https://github.com/neelance/go/issues/19)

[neelance]

@bradfitz and the Go team: How do you generally approach the question of whether to add some new API or not? What are the characteristics of idiomatic Go APIs?

[bradfitz]

Well, if syscall/js has no API compatibility promises, it's less of an issue.

I can't possibly list all the characteristics of idiomatic Go APIs briefly here in a comment. Basically it needs to look & feel like everything else in the standard library. But I see no reason we shouldn't be able to pass a []float32 to JavaScript. reflect.ValueOf supports it, of course.

[rsc]

/cc @cherrymui

[hajimehoshi]

What's going on this?

[ianlancetaylor]

It seems fine to add other types as long as they are unambiguous and useful. Should we extend the set of supported types to include slices of all supported types? Will passing a slice always imply copying all the elements?

[hajimehoshi]

Should we extend the set of supported types to include slices of all supported types?

I think supporting TypedArray (e.g. Float32Array for []float32) is enough.

Will passing a slice always imply copying all the elements?

What about []byte? Is it copied?

[neelance]

There is no copying from []byte to Uint8Array. The Uint8Array is backed by the section of the WebAssembly linear memory which holds the data of the []byte.

I agree that we should add the other typed arrays (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays).

[gopherbot]

Change https://golang.org/cl/121215 mentions this issue: syscall/js: add support for all typed arrays