A new ES6 draft is available

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Oct 1 09:54:01 PDT 2013


On Oct 1, 2013, at 3:10 AM, Andreas Rossberg wrote:

> On 30 September 2013 18:20, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> The lastest draft throws when doing an implicitly ToString conversion  [1]
>> of a Symbol primitive value. This means that  (aSymbol + "suffix") or
>> ("prefix" + aSymbol) [2] will throw, which was the case that I believe
>> people were most concerned about.
>> 
>> ToNumber conversion of a Symbol value is currently specified [3] as
>> producing a NaN for implicit numeric conversions of Symbols resulting in NaN
>> values that will propagate through numeric computations.  We could make
>> ToNumber throw for Symbol values but NaN seems more consistent with the ES
>> handling of invalid numeric conversions.
>> 
>> ToBoolean of a String value is defined[3] to return true.  This seems
>> consistent with the rest of ES, although it would be easy enough to define
>> this conversion to throw.
>> 
>> This isn't current in the spec, but we should probably also make implicit
>> string or number conversions of Symbol wrappers throw.  We can to this
>> simply by defining a @@ToPrimitive method [4] on Symbol.prototype that
>> throws .
> 
> OK, thanks for the summary, that makes sense. The one worry I have,
> though, is that not tainting S.p.toString itself will miss cases where
> code tries to convert some value x to a property name by explicitly
> calling x.toString(). Currently, that works for everything but null
> and undefined, so I assume that this pattern is used quite a bit.

Do you think thing it really is? Any value (other than null and undefined) automatically converts to a string when used as a property selector.  so there really isn't any reason (other than lack of knowledge) for someone to explicitly toString values before using them as a property key.  On the other hand, there are plenty of reasons in other use cases where someone might explicitly toString  because they actually want a string description of a value.

Either choice we make here is probably going to trip up some code.  I think what I've specified is the best set of trade-offs, but I willing to be convinced otherwise.  I suspect hard evidence supporting either alternative is hard to find 
> 
>> Because, all of the appropriate implicit conversions produce error results,
>> I didn't see any real reason why an explicit call to
>> String.prototype.toString should throw.  This certainly seems like a
>> reasonable way for a program to explicitly convert a Symbol value to a
>> string value for debugging, logging, or other proposes.  This method is
>> currently defined [5] to produce a string of the form "Symbol(<descriptive
>> string provided when created>)". (modulo a small spec. bug)
> 
> There always is the generic Object.prototype.toString that can be made
> to handle symbols. That is what V8 currently does (producing a string
> just like you describe above).
> 

But this forces such code to be rewritten to special case Symbol values (assuming that they don't want, for example, string values and Arrays to display as [object. String] and [object Array]).  Also, the spec. current says that O.P.toString for a Symbol returns [object Symbol] rather than Symbol(<descriptive string provided when created>).  This is to keep it consistent with other types of values and code that expects O.p.toString to always produce the [object <name>] pattern.




> /Andreas
> 
> 
>> As discussed at the meeting, (new Symbol) will throw.  This is accomplished
>> by making Symbol's @@create method [6] throw.
>> 
>> Object(aSymbol) is currently spec'ed to return a wrapper for the Symbol via
>> a call to ToObject [7]. While idea of throwing was mentioned at the meeting,
>> I'm not sure why it should be special cased to throw.  This is how a
>> programmer would generically convert primitive values to objects in
>> situations where this is necessary.  For example,
>>     "toString" in Object(expr)
>> Note that a call to ToObject is also how the implicit conversions used to
>> deference Reference values with primitive value bases (eg, aSymbol.foo)
>> works.
>> 
>> I'm not sure why my change log says (new Object(Symbol())) throws because
>> that isn't actually in the draft [9].  Perhaps I was about to make that
>> change, based upon the meeting minutes, and got interrupted or something.
>> Regardless, it does need to do something.  The most consistent thing would
>> be to treat it, like all other primitive values, as a request to create a
>> Symbol wrapper object.
>> 
>> 
>> Allen
>> 
>> 
>> 
>> 
>> [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.8
>> [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-12.6.2.1
>> [3] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.2
>> [4] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.1
>> [5] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.4.3.2
>> [6] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.4.2.9
>> [7] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.9
>> [8] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.1.2.1
>> [9] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-19.1.2.1
> 



More information about the es-discuss mailing list