Editorial: Convert @@ notation to intrinsics notation for well-known Symbols

[ljharb]

• this avoids a conceptual conflict with decorators, when they land

Open to bikesheds; other alternatives I considered:

• explicitly using intrinsics, ie, %SymbolSpecies%, and hardcoding that table, while removing the "well-known symbols table". This felt like it would lose some clarity around intrinsics vs well-known-symbols.
• Using %Symbol%species% - this would require upstream support in ecmarkup, so i opted not to do it for now.
• something else?

[gibson042]

Will this interact with special treatment of %% by ecmarkup (e.g., for "%%Internal%%" in spec → HTML)? And as a meta question, do we want to introduce auto-linking of well-known symbols if we're changing their representation?

[ljharb]

@gibson042 i would love to see auto-linking of well-known symbols, with or without this change.

I've tested the HTML output locally and atm they don't link anywhere, before or after.

[annevk]

This would also affect the HTML Standard.

cc @domenic

[domenic]

Happy with whatever. It would be nice cross-SDO citizenship work to make a corresponding HTML Standard PR, but it's certainly not required.

[ljharb]

@domenic i'm happy to try my hand at that once an approach gets consensus here, prior to merging this one.

[littledan]

Would it be possible to use a syntax more similar to Symbol.foo, so that it looks more similar to how JavaScript developers refer to the same thing?

[ljharb]

What’d you have in mind? It would have to be apparent that it’s not a property lookup on %Symbol%, i suspect.

[littledan]

Sorry, I don't have a concrete suggestion, and agree it shouldn't imply actual property access. But I would prefer that editorial churn like this would somehow inch us closer to being readable by normal programmers. @@ is now understood by a small set of people outside TC39; using a new syntax will make it harder to understand for that see while keeping it unintuitive for the big majority.

[bakkot]

My preference would be to use the %SymbolSpecies% notation and move the well-known symbols table to immediately following the intrinsics table. That way we reduce the total number of novel syntaxes in the spec. I don't actually think there is much of an important distinction between intrinsics and well-known symbols except for the cross-realm interaction. They're similar enough that it makes sense to put them near each other and use the same syntax, IMO.

[ljharb]

@bakkot i initially looked at doing that, but it seemed like a loss to remove the useful info in this section.

[bakkot]

See also #385.

[bakkot]

figure-2.png also needs to be updated, since it contains the text @@hasInstance.

[zenparsing]

I'm thinking that we should leave things the way they are for now, since @@ is well-understood, fairly readable, and used by other specs.

[michaelficarra]

Decision from the editor call today was to change @@symbolName notation to %Symbol.symbolName% for consistency with other instrinsics.

[ljharb]

True enough, but that's often unavoidable, and in this case, it'll be far more confusing if we have a spec with both decorators and @@ in it.

[Josh-Cena]

Decorators don't use @@ though, and code entities are typeset differently in the spec, if they are used at all. I see it can be confusing for MDN (which is another thing to think about, for us!), but not for the spec.

[jmdyck]

You gave a new clause id to every intrinsic with the property key %Symbol.foo%, except for:

• RegExp.prototype [ %Symbol.matchAll% ]
• %AsyncIteratorPrototype% [ %Symbol.asyncIterator% ]
• AsyncFunction.prototype [ %Symbol.toStringTag% ]

Did you intend to skip those?

Apart from that, looks okay to me.

[ljharb]

I didn't do it intentionally, it's just that I only changed the ones that had @@ in them.

I could change them to be consistent, but I'm not sure if that's worth the churn + oldids.

[jmdyck]

I didn't do it intentionally, it's just that I only changed the ones that had @@ in them.

That was my guess at first, but then I noticed that you had introduced new ids to replace

• sec-asyncgeneratorfunction-prototype-tostringtag
• sec-asyncgenerator-prototype-tostringtag

which don't have @@.

[ljharb]

Guess I was just being inconsistent in my application then :-) I'll update them to match.

[michaelficarra]

Still LGTM.

[ljharb]

HTML PRs:

• Update @@foo symbol notation to %Symbol.foo% notation whatwg/webidl#1415
• Update @@foo symbol notation to %Symbol.foo% notation whatwg/html#10450

[Josh-Cena]

@ljharb Out of curiosity: what's up with "luke_skywalker"?

[ljharb]

@Josh-Cena this PR kills at-at's

[Josh-Cena]

Oh! lmao 😄

[domenic]

Just want to drop in with an extra thanks to @ljharb for doing the HTML and Web IDL PRs. That kind of cross-ecosystem citizenship is much appreciated.

[linusg]

PR for ECMA-402: tc39/ecma402#905

[ljharb]

whoops, i should have made that one too. thanks!