whatwg
Buffer source types infrastructure
The algorithms provided in https://webidl.spec.whatwg.org/#es-buffer-source-types are a little shaky as the [AllowResizable] and [AllowShared] extended attributes end up changing the IDL type. Thus in principle these algorithms cannot be used if you have an IDL object for a view that points to a shared buffer, for instance.
Properly changing the types to be maximally inclusive would have some downstream repercussions and we'd also want to be careful that whatever maximally-inclusive IDL typedef we create here can be used for any future expansions of these buffers as well, should they happen. (Unless we're happy to do this again, but meh.)
Thus in principle these algorithms cannot be used if you have an IDL object for a view that points to a shared buffer, for instance.
I’m having trouble understanding this statement. Apologies if I’m the only one who doesn’t get it (since it doesn’t especially matter if I do), but would you mind expanding that or illustrating it with an example?
https://webidl.spec.whatwg.org/#AllowResizable
it creates a new IDL type that allows the buffer source type to be backed by an ECMAScript ArrayBuffer that is resizable
But then https://webidl.spec.whatwg.org/#buffersource-byte-length takes a BufferSource so you couldn't use that to get the length of an IDL type that includes [AllowResizable].
Ah gotcha. I think this text at the start of 3.2 was probably meant to address that for conversions and most conversion-related algs:
Note that the sub-sections and algorithms below also apply to annotated types created by applying extended attributes to the types named in their headers.
...which is kind of magical and yeah, it takes a very generous interpretation for that to make sense for the BufferSource algorithms at all (or even the conversions? the header text there is “Buffer source types” and [AllowShared] Buffer source types isn’t a thing, so it’s like a second layer of implicit expansions or something).