Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

FERREIRA, ERIC B

Some teams opt to use exclusively template strings in their code (see template literals are strictly better strings for some reasoning).

 

This is almost supported by ECMA, but for the fact that `StringLiteral` is expressly defined as either a single quote or double quote string, excluding `NoSubstitutionTemplate`s.

 

I contend that adding `NoSubstitutionTemplate`s to the definition of `StringLiteral` will bring the benefit of allowing teams to completely opt to use only template strings instead of mixing quote marks, while having very little risk or downside, if any at all.

 

`NoSubstitutionTemplate`s by nature are completely defined at "compile" time, essentially being exact same in functionality as standard `StringLiteral`s. Let's make it so in the grammar as well?


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

T.J. Crowder-2
On Wed, Jan 9, 2019 at 5:36 PM FERREIRA, ERIC B
<[hidden email]> wrote:
> I contend that adding `NoSubstitutionTemplate`s to the definition of
> `StringLiteral` will bring the benefit of allowing teams to
> completely opt to use only template strings instead of mixing quote
> marks, while having very little risk or downside, if any at all.

I've been toying with defaulting to template literals for some time. :-)

Interesting idea. Where specifically do you see benefits of this
change? The only places that immediately jump out to me are

* "use strict", mentioned in your linked article
* Quoted property names in object initializers (aka "object literals")
-- oddly not mentioned in that article (it mentions JSON, but not
object initializers)

That second one could be a bit of a footgun for people, who may trip
over this working:

```js
const obj = {`I have a space`: `bar`};
```

...but this failing:

```js
const obj = {`I have a space ${x}`: `bar`};
```

...because that's not a NoSubstitutionTemplate and so it needs to be a
computed property name.

Are there other places?

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

Jordan Harband
import path specifiers are another.

On Wed, Jan 9, 2019 at 10:16 AM T.J. Crowder <[hidden email]> wrote:
On Wed, Jan 9, 2019 at 5:36 PM FERREIRA, ERIC B
<[hidden email]> wrote:
> I contend that adding `NoSubstitutionTemplate`s to the definition of
> `StringLiteral` will bring the benefit of allowing teams to
> completely opt to use only template strings instead of mixing quote
> marks, while having very little risk or downside, if any at all.

I've been toying with defaulting to template literals for some time. :-)

Interesting idea. Where specifically do you see benefits of this
change? The only places that immediately jump out to me are

* "use strict", mentioned in your linked article
* Quoted property names in object initializers (aka "object literals")
-- oddly not mentioned in that article (it mentions JSON, but not
object initializers)

That second one could be a bit of a footgun for people, who may trip
over this working:

```js
const obj = {`I have a space`: `bar`};
```

...but this failing:

```js
const obj = {`I have a space ${x}`: `bar`};
```

...because that's not a NoSubstitutionTemplate and so it needs to be a
computed property name.

Are there other places?

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

Andrea Giammarchi-2
I dare saying tags are another issue here, 'cause "abc" === "abc", and with an identity function such `const id = o => o`, `id("abc") === id("abc")` but due latest changes to template literals, id`abc` !== id`abc` so it's easily misleading in the tagged case.

On Wed, Jan 9, 2019 at 7:53 PM Jordan Harband <[hidden email]> wrote:
import path specifiers are another.

On Wed, Jan 9, 2019 at 10:16 AM T.J. Crowder <[hidden email]> wrote:
On Wed, Jan 9, 2019 at 5:36 PM FERREIRA, ERIC B
<[hidden email]> wrote:
> I contend that adding `NoSubstitutionTemplate`s to the definition of
> `StringLiteral` will bring the benefit of allowing teams to
> completely opt to use only template strings instead of mixing quote
> marks, while having very little risk or downside, if any at all.

I've been toying with defaulting to template literals for some time. :-)

Interesting idea. Where specifically do you see benefits of this
change? The only places that immediately jump out to me are

* "use strict", mentioned in your linked article
* Quoted property names in object initializers (aka "object literals")
-- oddly not mentioned in that article (it mentions JSON, but not
object initializers)

That second one could be a bit of a footgun for people, who may trip
over this working:

```js
const obj = {`I have a space`: `bar`};
```

...but this failing:

```js
const obj = {`I have a space ${x}`: `bar`};
```

...because that's not a NoSubstitutionTemplate and so it needs to be a
computed property name.

Are there other places?

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

T.J. Crowder-2
On Wed, Jan 9, 2019 at 7:40 PM Andrea Giammarchi
<[hidden email]> wrote:
> I dare saying tags are another issue here, 'cause "abc" === "abc",
>  and with an identity function such `const id = o => o`,
> `id("abc") === id("abc")` but due latest changes to template
> literals, id`abc` !== id`abc` so it's easily misleading in the
> tagged case.

Very good point, but at least tagging is its own thing.

What "recent changes" are you referring to? Surely

```js
id`abc` === id`abc`
```

with that version of `id` was always `false`? You can't reuse the
array from the first call to call the tag function the second time,
what if the function modified the array? (Presumably if it *is* a
change, that's *why* it was changed... :- ) )

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

Mark Miller-2
Template is transitively frozen, so it cannot be mutated in place.


On Wed, Jan 9, 2019 at 11:49 AM T.J. Crowder <[hidden email]> wrote:
On Wed, Jan 9, 2019 at 7:40 PM Andrea Giammarchi
<[hidden email]> wrote:
> I dare saying tags are another issue here, 'cause "abc" === "abc",
>  and with an identity function such `const id = o => o`,
> `id("abc") === id("abc")` but due latest changes to template
> literals, id`abc` !== id`abc` so it's easily misleading in the
> tagged case.

Very good point, but at least tagging is its own thing.

What "recent changes" are you referring to? Surely

```js
id`abc` === id`abc`
```

with that version of `id` was always `false`? You can't reuse the
array from the first call to call the tag function the second time,
what if the function modified the array? (Presumably if it *is* a
change, that's *why* it was changed... :- ) )

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


--
  Cheers,
  --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Add `NoSubstitutionTemplate` to `StringLiteral` Definition

Isiah Meadows-2
In reply to this post by T.J. Crowder-2
The first argument to each is an array of items. It's the same per
lexical occurrence, but it's *not* the same across multiple lexical
templates, even if they represent the same sequence of characters with
interpolation expressions removed. That above expression is
semantically more like this: `id(Object.assign(["abc"], {raw: "abc}))
=== id(Object.assign(["abc"], {raw: "abc}))`, which obviously should
evaluate to `false`.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Wed, Jan 9, 2019 at 2:49 PM T.J. Crowder
<[hidden email]> wrote:

>
> On Wed, Jan 9, 2019 at 7:40 PM Andrea Giammarchi
> <[hidden email]> wrote:
> > I dare saying tags are another issue here, 'cause "abc" === "abc",
> >  and with an identity function such `const id = o => o`,
> > `id("abc") === id("abc")` but due latest changes to template
> > literals, id`abc` !== id`abc` so it's easily misleading in the
> > tagged case.
>
> Very good point, but at least tagging is its own thing.
>
> What "recent changes" are you referring to? Surely
>
> ```js
> id`abc` === id`abc`
> ```
>
> with that version of `id` was always `false`? You can't reuse the
> array from the first call to call the tag function the second time,
> what if the function modified the array? (Presumably if it *is* a
> change, that's *why* it was changed... :- ) )
>
> -- T.J. Crowder
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss