Shu-yu Guo

That's a good goal, but the reality of memory models is that no implementer will read the actual memory model for implementation guidance. They will read the non normative guidelines...

Editorially lgtm. Editorial review: - `Array.prototype.toSpliced` step 4 and `%TypedArray%.prototype.toSpliced` step 5 aren't really needed. The `max` and `min` functions are defined over the extended reals (i.e. reals + positive...

> Both of your alternative approaches make a new array, and then mutate it. The goal is to avoid the mutation entirely. The current proposal certainly still has mutation in...

> @syg in what way? each of the methods in this proposal returns a new array and does not mutate the original one. Well you didn't say "mutation of the...

I am very happy by the reception but I think it’s still too early. There’s a lot of the corners of the spec that are just missing. I’ll make an...

Excellent, please file issues on the spec repo. > On May 25, 2018, at 11:23, James Browning wrote: > > I don't really intend to publish anything per se other...

@kripken This all seems most cleanly solved by making sure the capabilities of `ArrayBuffer`, `SharedArrayBuffer`, and `WebAssembly.Memory` stay in sync. To wit, I'd be happy to resurrect the `realloc` portion...

> do you mean the entire issue? Yeah, I mean the entire issue. > If wasm calls memory.grow internally, we need the JS buffer and views to be updated. Even...

> Maybe I'm misunderstanding you, but I think realloc helps us do something cleaner in JS when a growth occurs, but we do still need to get notified, so we...

From my brief chats with @binji about the matter, shared memory would have different realloc restrictions than non-shared memory, and I don't really see another way than following what wasm...