read-only ArrayBuffer is strange

[domenic]

I think you want to create a normal ArrayBuffer, then freeze it (by applying SetIntegrityLevel(O, "frozen")). Note that this makes it immutable, not just read-only; I couldn't tell whether you were modifying the values from the spec or not.

[jyasskin]

Thanks. I'm not modifying the values from the spec once it's created, and I'd like to get back to actual ES types. However, I tried Object.freeze(buffer), and it didn't actually freeze the buffer. This is probably something for which I need to ask for an ES change.

[domenic]

Oh, you're right of course; that doesn't freeze the underlying data. Dang. Blocking specs on TC39 is never a path to success :-/.

Maybe the read-only ArrayBuffer cases could be changed to functions that return normal ArrayBuffers?

[jyasskin]

For the uses in the main spec, writable ArrayBuffers aren't terrible. They're fields reporting data to the website, and the UA would never read any mutations the website makes. I'd rather have them writable than make them functions, although that's a matter of taste.

The scanning spec does use some ArrayBuffer fields after they're exposed to websites. I'm inclined to leave the read-only ArrayBuffers in the spec until someone starts implementing Scanning, just in case TC39 comes through quickly, but there are also several alternatives we can fall back to at that point.

[bzbarsky]

I really doubt TC39 will come through on this; it's been discussed before and rejected because of fairly nasty performance implications for code that manipulates typed arrays.

I strongly suggest not specifying something that is not actually implementable.

[erights]

I really doubt TC39 will come through on this; it's been discussed before and rejected because of fairly nasty performance implications for code that manipulates typed arrays.

I strongly suggest not specifying something that is not actually implementable.

https://github.com/tc39/proposal-immutable-arraybuffer is now at Stage 2, has enthusiastic support from some implementations, and has not (yet?) had any serious objections. It does not make the ArrayBuffer immutable in place, but rather makes a new Immutable ArrayBuffer while detaching the original, so that the operation is zero-copy for the data itself.

[erights]

Would proposed JavaScript Immutable ArrayBuffers help? Would they conflict?

https://github.com/tc39/proposal-immutable-arraybuffer is now at Stage 2, has enthusiastic support from some implementations, and has not (yet?) had any serious objections. It does not make the ArrayBuffer immutable in place, but rather makes a new Immutable ArrayBuffer while detaching the original, so that the operation is zero-copy for the data itself.

Ping. I am about to ask for advancement to stage 2.7 at tc39, so any timely answer or opinions would be most useful. Thanks!

[reillyeon]

Overall I'm supportive of this however given that Web Bluetooth has been deployed for many years it would take some investigation to determine whether the ArrayBuffers it exposes (BluetoothRemoteGATTCharacteristic.value being the most obvious example) can be made immutable without affecting compatibility. For the most part, as @jyasskin mentioned, edits to the buffer by script can be effectively ignored by the implementation because it only ever writes to the buffer. Reading back over the Scanning API I'm not sure why it was necessary to use an ArrayBuffer in a way that would make script modifications relevant and the spec could be modified to remove this ambiguity completely.

It think this matters more to specs like WebGPU and WebNN where it is useful to model an immutable memory region because the underlying platform requires it (e.g. a device buffer which is mapped read-only).