Is frozen-ness insufficient?

(In reply to comment #0)
> Would be nice if the spec provided some way in IDL to express that an array
> is readonly and/or fixed length. 
Are there cases of fixed length in the platform?

(In reply to comment #1)
> Is frozen-ness insufficient?
I don't think there is a WebIDL way to express that an object is frozen yet (though I agree that could be a solution here)

frozen-ness is not the right thing.

The point of readonly or fixed-length arrays is to return an arraylike object to a caller with the following properties:

1)  The caller can read things from the arraylike.
2)  The caller cannot write things to the arraylike.
3)  The _callee_ can write things to the arraylike as needed.

Most cases where you'd not want the callee to later modify the object just want pass-by-value semantics and actual JS arrays.

(In reply to comment #3)
> frozen-ness is not the right thing.
> 
> The point of readonly or fixed-length arrays is to return an arraylike
> object to a caller with the following properties:
> 
> 1)  The caller can read things from the arraylike.
> 2)  The caller cannot write things to the arraylike.
> 3)  The _callee_ can write things to the arraylike as needed.
> 
> Most cases where you'd not want the callee to later modify the object just
> want pass-by-value semantics and actual JS arrays.

Got it, thanks for the clarification

We used to have this, in T[]. It was removed in favor of FrozenArray and a general movement toward a different pattern of returning a new frozen array object each time. I think we won't go back to a T[]-like world, unless ES somehow add readonly-but-not-immutable arrays as a first-class concept.