All string literals must be code formatted

[rwaldron]

@bterlson why have you changed the convention for string literals?

to:

[bterlson]

Caridy just pointed me to this, sorry. It was changed as it was annoying - some quotes aren't the start of strings. In general, *'s are used for values, so it makes sense to use them for string values as well.

[spectranaut]

It looks like Ecma-262 has two conventions for string literals now.

In String.prototype.normalize we see `"string"`:
If _f_ is not one of `"NFC"`, `"NFD"`, `"NFKC"`, or `"NFKD"`, throw a *RangeError* exception.

Then in String.prototype.padStart we see *"string"*:
Return ? StringPad(_O_, _maxLength_, _fillString_, *"start"*).

Which is correct? Ecma-402 only uses `"string"`. Should we change to *"string"* as seems to be @bterlson's preference from 3 years ago? :) @leobalter @sffc @ljharb

[ljharb]

cc @rkirsling, who i believe has an open PR to unify these conventions?

[rkirsling]

It's true that updating `"foo"` → *"foo"* is meant to follow tc39/ecma262#1302, which mainly addresses the current inconsistency in `foo` vs. `"foo"` for properties, but that's one already been open for a year, so it's completely taken the wind out of my sails... 😭

[ljharb]

I plan to merge that PR within the next few weeks, for the record, just after merging a few others that need to be prioritized (and after rebasing 1302), with perhaps minimal adjustments - so I think that perhaps 402 should hold off making any changes until after that lands, at which point the overarching convention in 262 will be *"string"*, and then 402 could make that change?

[rkirsling]

Yay! Sounds like a plan to me.

[ljharb]

tc39/ecma262#1302 has been merged.

[sffc]

Excellent. @spectranaut @leobalter can you follow up with a PR to ECMA-402 following the latest convention of ECMA-262?

[spectranaut]

Yup, I can do this Thursday.

[spectranaut]

Wow, I can believe that after doing this work I'm convinced we should leave all string literals as `"string"` instead of changing it to *"string"*, especially given the changes @rkirsling made.

Ultimately, I was convinced for mostly two reasons:

1. I think it will be confusing for future contributors to know when to use which convention. If property names look like strings (because they are quoted) but you use the *"string"* convention, AND all other string literals use the `"string"` convention, I think contributors who are newer to the spec will make endless mistakes (where someone just copies either convention for their string literals or properties).

2. Unlike we assume above, the majority of the string literals in 262 still use the `"string"` convention. And all of 402 does. I'm used to seeing string literals in the consolas font family and I image most contributors/readers of the spec are as well. See the example screenshots below.

I'd like to close this and open an issue on 262 to change the few string cases that use *"string"* back to `"string"`, unless @ljharb or @rkirsling can provide overriding reasons to switch both specs to *"string"* anyway?

For an example, look how weird this table looks (and the following algorithm) if we change the string literals and not the properties:

For reference, the spec as it is now:

[rkirsling]

Sorry @spectranaut, I meant to reiterate my earlier comment after tc39/ecma262#1302 was merged, but I failed to do so. You're absolutely right that 262 is in a weird state at this moment. This is because 1302 was merely the long-standing prerequisite for doing the parallel work to this issue over there.

The current plan is that after tc39/ecma262#1724 and tc39/ecma262#1725 are merged, all remaining cases of `"foo"` will be converted to *"foo"* in one fell swoop.

[spectranaut]

Oh right I think I understand, but I still think we shouldn't do it! I don't think I agree that `"foo"` should be converted to *"foo"*.