iterate and enumerate trap signature inconsistency

[David Bruant]

Le 11/09/2012 21:37, Tom Van Cutsem a écrit :
> The enumerate() trap predates the TC39 blessing of iterators, but IIRC
> we did agree to revisit its signature once iterators were in. I think
> having the enumerate() trap return an iterator is perfectly sensible.
> There's a catch, however:
>
> As currently specified, direct proxies enforce that the enumerate()
> trap doesn't return duplicate property names. Now, as Allen hints at,
> we could make the proxy return its own outer iterator that exhausts
> the inner iterator returned by the enumerate() trap to insert extra
> checks. But for the proxy to check for duplicates, it must remember
> all property names previously produced by the inner iterator. So the
> main benefit of using an iterator, namely that the entire collection
> of generated values doesn't need to be retained in memory, seems lost.
I don't remember what the rational of the duplicate check was. Do we
really need it?
A lot of invariants are here for the sake of robustness/security
(especially non-configurable/non-writable/non-extensible-related
invariants), but it doesn't seem duplicate keys will make code less
robust or secure.

Unless there are strong reasons to preserve this invariant, it could be
dropped, couldn't it?

David