Perhaps @@unscopable shouldn't be a Set...

Andreas Rossberg rossberg at
Wed Sep 25 14:41:01 PDT 2013

I sympathise with Allen's concern. Implementations might have layering
issues as well, especially if Set is mostly self-hosted. We should
make it a plain array.


On 25 September 2013 22:34, Erik Arvidsson <erik.arvidsson at> wrote:
> Conceptually it is a set but I don't think anyone cares enough to
> oppose this being an array given that it is a cleaner layering of the
> spec.
> On Wed, Sep 25, 2013 at 1:07 PM, Allen Wirfs-Brock
> <allen at> wrote:
>> At last weeks TC39 meeting we had consensus that the value of the
>> @@unscopable property should be a Set
>> As I begin to look at implementing this (and the other @@unscopable changes
>> from the meeting) I'm not so sure that Set is such a good idea.  My basic
>> concern is that @@unscopable operates at a very low level of the ES name
>> binding resolution mechanism.  Set exists at a much higher conceptual level
>> of the ES library and (until now) there was nothing in the fundamental
>> language semantics of ES that depends upon the existence of a library Set
>> object. Now that I have thought about this,  it seems fundamentally wrong to
>> unnecessarily create such an up-dependency.
>> I think we will have a cleaner semantics if we continue to treat an
>> @@unscopable value as an array-like object for the purpose of accessing its
>> property blacklist. Implementations, if they wish, can us2 caching scheme to
>> obtain sub-linear time access to an @@unscopable blacklist.
>> In light of this consideration, does anybody still want to argue that we
>> should require an @@unscopable value to be a Set instance?
>> Allen
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> --
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list