Editorial: Fix misformatted occurences of things that are "string values"

[rwaldron]

No description provided.

[rkirsling]

This is the opposite policy of #1302 (see fourth commit). My understanding is that we're currently using code for many things that really ought to be value, but it will take time to fully correct this throughout the spec.

[ljharb]

Oops - it’s hard to keep track of this stuff. Perhaps the first step should be documenting the notational conventions we want in the spec, precisely, and then it will be clearer what changes need to be made?

[rkirsling]

Yeah, I agree that it's hard to keep track of—it's documented here, but I only know that since @bterlson and @jmdyck explained it to me in an earlier PR.

[jmdyck]

As I said over in PR 1239:

(Asterisks vs backticks has come up before. The problem is that pretty much anything that the spec uses to denote a "language value" would also be valid code that has the same value. So to decide between asterisk and backtick, you have to decide whether the spec is talking about a value, or talking about code with that value, which is not always clear. Probably it should go to the former more than it currently does.)

@ljharb:

Perhaps the first step should be documenting the notational conventions we want in the spec, precisely, and then it will be clearer what changes need to be made?

Yup.

One possible policy would be: in cases where asterisk and backtick could arguably both apply, use asterisk. I.e., use backticks only for cases where the spec is clearly talking about a snippet of ECMAScript source text.

(Note that the reverse policy, of resolving 'ambiguous' cases in favor of backtick, would leave almost no uses of asterisks, I think.)

And actually, we might want to start with a policy about the uses of tildes. E.g.: if some operation parameter/alias accepts a small set of known string values, with no visibility of those values to userland, then don't use string values, use a set of spec values (with tildes) instead. (Note that small enumerations are better for static analysis.)

[rwaldron]

These changes are only being applied to string values that are actual literal strings in the spec. I'm surprised that there is contention between the formatting of things like TypeError, true, null, undefined (values), and "key+value", "classConstructor", "get", "enumerable" (literal string values). In any case, this changeset serves only to fix a handful of literal string values that weren't properly formatted.

[rkirsling]

@rwaldron What I mean is that your commit is doing the literal opposite thing of what I was advised to do in the commit I mentioned above (which has been pending merge for a good long while). 😄

(That PR is admittedly a bit confusing with respect to this exact point, because I've only added asterisks for string values that are explicitly referred to as a value, whereas it would be possible to go even further and turn property names from "foo" into "foo" right away too, as mentioned at the end of this comment.)

Any consistent policy is potentially fine by me and we should definitely nail it down and be up front about it, but this PR can't co-exist with #1302, so something has to give. 🙂

[rwaldron]

@rkirsling this PR follows a convention that has existed since ES1. It seems like a few places were mis-formatted, maybe during a revision of the algorithms or the addition of new normative prose, which is what I'm correcting here.

[ljharb]

I think we can merge this - since it's a small number of changes - and continue pursuing a larger codification in #1302.

[rkirsling]

@rwaldron Right, I understand that you're changing stuff that's out of alignment with the status quo, and indeed, what we're discussing would be the beginning of a new policy. I didn't mean to suggest that this PR is "wrong" in any way or that I want to leave the spec in an inconsistent state; I'm trying to be diligent in pointing out that it's in contradiction with what I've understood to be our desired policy.

To be fully concrete, your PR changes *""* to `""` to make

<p>The initial value of the _@@toStringTag_ property is the String value `"RegExp String Iterator"`.</p>

while a commit on my PR does the reverse to make

<p>The initial value of the @@toStringTag property is the String value *"String Iterator"*.</p>

so I was hoping we would choose one or the other instead of presumably needing to add a revert commit for this to a PR that's been awaiting merge for many months.

[rkirsling]

The italics on @@toStringTag here seem to be a mistake too.

[rwaldron]

@rkirsling indeed it is. I wasn't looking for anything outside of the cases that I was trying to correct, but I don't mind making another pass to fix any incorrect formatting that matches this pattern.