domenic at domenicdenicola.com (2013-10-13T02:45:39.793Z)
On Sep 30, 2013, at 4:53 AM, Andreas Rossberg wrote:
> Yes, but there seems nothing inherently risky or error-prone in
> (purposefully and explicitly) creating a wrapper object. And since you
> can do it for other primitive types, I think the scales weigh towards
> consistency on this one.
At this point, we should probably discuss what is actually in the spec. draft rather than the change summary or the meeting notes.
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 .
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)
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
On Sep 30, 2013, at 4:53 AM, Andreas Rossberg wrote: > On 30 September 2013 13:41, Domenic Denicola > <domenic at domenicdenicola.com> wrote: >> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of >> >> >>> I can't remember any discussion about Object(Symbol()). Why should it be >>> disallowed? >>> >>> On the other hand, we agreed the other week on making 'new Symbol' and >>> Symbol.prototype.toString throw. That should address all likely accidents. >> >> I only remember Dave briefly mentioning it as one of the potential ways to get a wrapper object; I don't remember a decision to prohibit it. >> >> On the other hand, this is somewhat attractive, as it prevents getting a symbol wrapper object except inside sloppy-mode methods/accessors added to `Symbol.prototype`, wherein `this` is a wrapper. Which means, unless I missed a case, that in strict mode it is impossible to create a symbol wrapper object. > > Yes, but there seems nothing inherently risky or error-prone in > (purposefully and explicitly) creating a wrapper object. And since you > can do it for other primitive types, I think the scales weigh towards > consistency on this one. At this point, we should probably discuss what is actually in the spec. draft rather than the change summary or the meeting notes. 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 . 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) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130930/848649b3/attachment-0001.html>