Disallow FrozenArray<> in argument lists, and maybe dictionaries and return types

[domenic]

What is the issue with the Web IDL Standard?

Argument lists should always accept sequences, not FrozenArray<>s. But some specs seem to use FrozenArray<>s as arguments. This never makes sense.

Similarly, it never makes sense to use FrozenArray<> as a type for an "input" dictionary. You should always use sequences.

---

Other "output" cases where we might want to disallow FrozenArray<>s are "output" dictionaries, and method return values.

In general, such APIs should be designed so that when you vend an object to the web developer, the developer can then mutate the object if they want. Taking an extra step to freeze them is unusual and kind of silly.

The exception is if some of these APIs are caching the FrozenArray<>s to avoid creating new JS Array values each time, for performance reasons. I'd be skeptical the performance issues here are really critical but it is a possible use case.

---

I'll file a variety of issues linking back to this one to see if we can clean up the ecosystem and then implement prohibitions in the spec.

• Using FrozenArray<> as an argument type:
  • Use of FrozenArray<SharedStorageUrlWithMetadata> as an argument type makes no sense WICG/shared-storage#143
  • AudioWorkletProcessCallback should not be a callback type WebAudio/web-audio-api#2581
• Using FrozenArray<> in a dictionary:
  • Use of FrozenArray<>s in dictionaries is unnecessary and bad immersive-web/hit-test#116
  • Why does this spec use dictionaries containing FrozenArray<>s, instead of sequence<>s? WICG/shape-detection-api#100
  • Use of FrozenArray<>s in dictionaries is unnecessary and bad immersive-web/webxr#1368
• Using FrozenArray<> as a method return type
  • Use of FrozenArray<>s for return types of methods is probably unnecessary immersive-web/hit-test#117

[saschanaz]

Would this completely remove JS-to-IDL conversion for FrozenArray or is there still a use case for that?

[hoch]

Thanks for opening an issue on Web Audio API, @domenic!

I have a follow up question on one of your points:

Similarly, it never makes sense to use FrozenArray<> as a type for an "input" dictionary. You should always use sequences.

Can you explain a bit more why it doesn't make sense? Also if this doesn't make sense, what would be the recommendation of FrozenArray in the AudioWorkletProcesor's process()? The original intention was to clarify that the array passed by the audio renderer is not mutable by the user code.

cc @padenot

[saschanaz]

Can you explain a bit more why it doesn't make sense? Also if this doesn't make sense, what would be the recommendation of FrozenArray in the AudioWorkletProcesor's process()? The original intention was to clarify that the array passed by the audio renderer is not mutable by the user code.

AFAICT receiving a FrozenArray is not very diffferent from receiving a sequence, per the step 1 of https://webidl.spec.whatwg.org/#js-frozen-array. The user code can't mutate the IDL converted sequence anyway because it gets the result of reconstruction from iterator: https://webidl.spec.whatwg.org/#js-sequence

[petervanderbeken]

Similarly, it never makes sense to use FrozenArray<> as a type for an "input" dictionary. You should always use sequences.

Can you explain a bit more why it doesn't make sense? Also if this doesn't make sense, what would be the recommendation of FrozenArray in the AudioWorkletProcesor's process()? The original intention was to clarify that the array passed by the audio renderer is not mutable by the user code.

I assume you wanted to ask about using them as types for arguments, since that's the case for Web Audio (not a dictionary). Note that Web Audio's use case is a bit special, since it's using them for a callback which needs argument conversion from WebIDL to ECMAScript. I think the main concern for this issue is avoiding the conversion from ECMAScript to WebIDL for arguments, but callbacks also use WebIDL argument lists. Removing them from argument lists in general will break the callback case too, which is why it would nice to remove that particular callback.

Regardless of whether Web Audio needs to use a FrozenArray for performance reasons, see the discussion in 2581 on why you might not actually need the WebIDL callback in the first place.