The Fate and Purpose of BufferSlice

[cwfitzgerald]

There's been a bit of discussion in the community about the difficulties in the current BufferSlice api. As such, we have been thinking about removing it entirely. However there was some discussion about potential use cases of it in #6309, so we figured we should make an issue to discuss what the api of BufferSlice should be, if it is to exist at all.

cc @kpreid

Some Arguments Against the Current Api:

• It is a deviation from the spec.
• The name BufferSlice implies that you can access the data inside the buffer.
• Users try to keep the BufferSlice around, but because of the strict lifetime, you can't keep it for more than a short period.

[kpreid]

I’ll try to have some thoughts about what would be an “actually actively-good version of BufferSlice”, but I don't have them right now. Some comments:

It is a deviation from the spec.

Note that it's easier in JavaScript to create an ad-hoc object, copy or inherit properties, etc., so it may be easier to deal with not having useful predefined struct types there.

Users try to keep the BufferSlice around, but because of the strict lifetime, you can't keep it for more than a short period.

This could be fixed by making BufferSlice generic or Cow-ish to allow owning the buffer, now that wgpu objects are all Clone-with-refcounting.

[cwfitzgerald]

Note no rush, this isn't a ticking timebomb, we'll let the discussion take its course.