Video Call: August 8th 2019

[jgravelle-google]

No registration required. Email jgravelle [ at ] google (dot) com for the meeting link. (Meeting will use Zoom software)

Meeting will start at 12noon PDT, and will last one hour (until 1pm PDT).

Please suggest agenda items as comments on this issue.

---

Notes here

[lukewagner]

Agenda item: naming/terminology (and what of ☃)

[lukewagner]

Another agenda item: idea for how to avoid slices/views altogether (at least until wasm adds a first-class sliceref)

[jgravelle-google]

Notes here

[PoignardAzur]

Reading the notes, it sounds like the semantics of passing/returning slices was discussed, but no conclusion was reached? Did I get that right?

@lukewagner Is sliceref as a first-class type defined somewhere? Like, is there a public proposal, or is it an informal idea?

[lukewagner]

In the call I basically just explained some recent thinking on whether we need slices/views. Namely:

1. passing out a view to linear memory (as a typed array view or sliceref) is a pretty dangerous thing; it means that you now have to worry about the lifetime of that region of memory (with "use after free" bugs if the caller and callee don't agree)
2. but a lot of Web APIs take views, where the host both reads and writes from/to the view
3. a sequence-of-bytes interface value could be optimized to do no more copying than a view when calling a host API (with the right adapter expressions)

And thus perhaps we can leave out slices, at least from the initial proposal so that we can focus on the safer, more composable value semantics.

I'm afraid there's no written-up proposal for sliceref; it's just a very old idea that we assume we'll get around to at some point in time. The idea is basically to have a first-class typed array view that wasm can dynamically load and store from, ideally being able to point into both linear memory and ArrayBuffers (on the web).