Buffer source types infrastructure

[annevk]

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.)

[bathos]

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?

[annevk]

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].

[bathos]

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).