Private symbols vs property attributes

[Andreas Rossberg]

We intend to have both "unique" and "private" symbols. The only
difference between the two is that the latter are filtered from
certain reflective operations.

I have come to think that this distinction is backwards. It is
attributing something to symbols that actually is an attribute of
properties. Symbols are just symbols. We should not piggyback them
with something that is not actually related to their own semantics as
such, but only their forwarding in specific client contexts.

Let's put the distinction where it belongs. There is no systematic
difference between privateness and non-enumerability, so they should
be handled analogously. I hence propose that we add a new attribute to
property descriptors, say, 'private'. Any property with this attribute
set to true is filtered by the relevant reflective operations. That
is, it is simply a stronger form of the non-enumerable attribute. (For
consistency a logically inverted attribute like 'reflectable' might be
preferable, but that's secondary.)

The only drawback I see with this approach is that we have to pick a
default. In particular, an assignment o[s] = v where s is a symbol
that does not exist yet on o can only have one meaning, either
consistently introducing a private property or a non-private one.
There are valid arguments for either choice, but I think making the
choice is doable. A property of the other form would have to be
introduced via Object.defineProperty, until we get more syntax
support. (Note that this only affects installing a new property, not
later assignments.)

/Andreas