symbols in template literals

Tab Atkins Jr. jackalmage at gmail.com
Fri Sep 12 09:58:01 PDT 2014


On Thu, Sep 11, 2014 at 3:29 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> On Sep 11, 2014, at 2:59 PM, Brendan Eich wrote:
>> Claude Pache wrote:
>>> Recently, `String(symbol)` has been modified in order to not throw, on the ground that it is an explicit conversion, and a safer one than `.toString()`. [1]
>>
>> And to cite the hazard, because obj[name +''] where name is a non-symbol must continue to work as it has, but if extant code like this suddenly is passed a symbol for name, we want a throw rather than an unintended property alias.
>>
>>> What about symbols in untagged templates?
>>>
>>>     function foo(num, sym) {
>>>         if (__debugMode)
>>>             window.alert( `Got arguments: ${num} and ${sym}`)
>>>         // ...
>>>     }
>>
>> Doesn't seem to have the property alias hazard. Seems explicit enough of a gesture to me to allow. My two cents, but only two (in a hurry, may be missing something).
>
> I see this, as the first step on a path of considering every use of ToString in the spec. and deciding whether it would be ok to use "ToStringSymbolAllowed" instead.  And the possible result being that some places where symbols are allowed and some where they aren't.  And know body remember which is which. It's probably better to have a consistent rule with one explicit exceptions rather than a loosely applied rule with many exceptions.

Agreed; keep it simple and consistent.  The main use-case for
stringifying symbols is debugging, and String(sym) allows that; keep
everything else throwing for sanity.

~TJ


More information about the es-discuss mailing list