search

whatwg / webidl

Web IDL Standard
https://webidl.spec.whatwg.org/
Other
410 stars 164 forks source link

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

Closed domenic closed 4 months ago

domenic commented 7 months ago

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.

saschanaz commented 7 months ago

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

hoch commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.