Current spec allow passing UInt32Array as argument in setBindGroup method for dynamicOffsetsData. This is inconsistent with other methods, such as writeBuffer or writeTexture which takes raw ArrayBuffer (AllowSharedBufferSource) instead of ArrayBufferView.

Having Uint32Array as input parameter for setBindGroup is problematic because in most typical use case it is called from WASM, which itself can allocate more memory using WebAssembly.Memory.prototype.grow method. Growing memory will make every ArrayBufferViews currently pointing to WASM memory invalid:

Every call to grow will detach any references to the old buffer, even for grow(0)! Detachment means that the ArrayBuffer's byteLength becomes zero, and it no longer has bytes accessible to JavaScript.

Because one cant trust that any previously created Uint32Array is still valid due potentially invalidated memory, a new Uint32Array view must be created every time setBindGroup is called, resulting garbage and other performance penalties.

Because new Uint32Array must be created, other parameters to setBindGroup "dynamicOffsetsDataStart" and "dynamicOffsetsDataLength" are useless because the Uint32Array can be constructed with correct offset and length at first place.

If setBindGroup had consistent with writeBuffer and writeTexture, allowing "AllowSharedBufferSource" instead of Uint32Array, there would not be reason to create new view for each call. Even when memory is grow, the reference to webassembly memory buffer is always safe, pointing to current memory in WASM module.