symbols in template literals

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]

What about symbols in untagged templates?

    function foo(num, sym) {
        if (__debugMode)
            window.alert( `Got arguments: ${num} and ${sym}`)
        // ...
    }

—Claude

[1] http://esdiscuss.org/topic/string-symbol

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).

/be

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.

Allen.

Allen Wirfs-Brock wrote:
> 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.

And of course one might write obj[`${name}`] if we did allow conversion 
to string there, and oops.

/be

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