Re: [heycam/webidl] non-readonly [FrozenArray] attributes are footguns as currently specced (#810)

I agree this is a problem.

I think one route toward fixing this is using the classes in #796 to completely replace all `FrozenArray<>` usage. What follows is my response to this thread, predicated on us deciding that is not sufficient and we want to keep frozen arrays.

---

My initial impulse was toward just "fixing" `FrozenArray<>` rather than introducing `[Cached]`, as I think "a frozen array type" is a reasonable semantic, and it'd cause a bit less churn for the ecosystem. However, it'd be good to hear if `[Cached]` has other use cases besides this one.

Another factor that makes me consider `[FrozenArray] sequence<>` over `FrozenArray<>` is that we could naturally restrict `[FrozenArray]` usage to attributes, ignoring it for dictionary members, operation arguments, or operation return values. I guess we might be able to restrict `FrozenArray<>` the same way, but it seems weirder.

Regardless, I think it's worth thinking through what we want the spec authoring experience to be. Here's a stab:

- readonly frozen array attribute:
  - Spec authors do not specify the getter behavior; that is auto-generated.
  - Spec authors can "**reset the frozen array value** for `instance`'s `attrName` to _x_" where _x_ is an Infra list/IDL sequence. This:
    - Clones _x_ and stores it as the backing list.
    - Creates a frozen JS array value and starts returning it from the getter.
  - Spec authors can reference "`instance`'s `attrName`'s **backing list**", which is an Infra list/IDL sequence. This can be "for each"ed over, etc., but must not be mutated. Instead of mutating it, spec authors must use "reset the frozen array value".
- non-readonly frozen array attribute:
  - Mostly the same as above, plus an auto-generated setter
  - Spec authors need to take care to re-consult the backing list, and not take a reference to it (unless they really do mean to store a snapshot of what it was, ignoring future author mutations).

This seems reasonable, although a bit fragile. Is it possible to improve?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/810#issuecomment-538651524