Editorial: stop using strings for special values by ljharb · Pull Request #2155 · tc39/ecma262

ljharb · 2020-08-26T23:21:12Z

This was extracted from #2154 so it could land separately.

This was extracted from tc39#2154 so it could land separately.

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

bakkot · 2020-09-08T02:10:58Z

There's another special string: "*", used in ImportEntry Records to indicate that the import request is for the target module's namespace object.

bakkot · 2020-09-08T02:12:53Z

            1. For each ExportEntry Record _e_ of _module_.[[IndirectExportEntries]], do
              1. Let _resolution_ be ? _module_.ResolveExport(_e_.[[ExportName]]).
-              1. If _resolution_ is *null* or *"ambiguous"*, throw a *SyntaxError* exception.
+              1. If _resolution_ is *null* or ~ambiguous~ throw a *SyntaxError* exception.


Suggested change

1. If _resolution_ is *null* or ~ambiguous~ throw a *SyntaxError* exception.

1. If _resolution_ is *null* or ~ambiguous~, throw a *SyntaxError* exception.

bakkot · 2020-09-08T02:16:01Z

-          1. Assert: Type(_name_) is String.
+          1. Assert: Either Type(_name_) is String, or _name_ is ~default~.
          1. If _environment_ is not *undefined*, then
            1. Perform _environment_.InitializeBinding(_name_, _value_).


I am pretty sure we shouldn't actually be attempting to initialize a binding named ~default~.

fixed in 870e5f7

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb · 2020-09-08T05:22:56Z

Handled the ImportEntry Records string in 158950a.

bakkot · 2020-09-08T20:13:22Z

          1. Let _value_ be ? BindingClassDeclarationEvaluation of |ClassDeclaration|.
          1. Let _className_ be the sole element of BoundNames of |ClassDeclaration|.
-          1. If _className_ is *"\*default\*"*, then
+          1. If _className_ is ~default~, then


I don't actually understand why we're making/initializing a binding here at all. Possibly some interaction with module instantiation I'm missing? Anyone know what's up with that?

bakkot · 2020-09-08T20:17:58Z

      <emu-grammar>GeneratorDeclaration : `function` `*` `(` FormalParameters `)` `{` GeneratorBody `}`</emu-grammar>
      <emu-alg>
-        1. Return &laquo; *"\*default\*"* &raquo;.
+        1. Return &laquo; ~default~ &raquo;.


I believe this still ends up making a binding named ~default~ in InitializeEnvironment of Source Text Module Records, step 23.

…tcampbell The "Arbitrary module namespace identifier names" spec PR allows to use "*" as a module export name, so we can no longer use that specific string to denote star-imports/exports. Probably the easiest way to work around this new restriction is to replace "*" with a nullptr string. Spec change: tc39/ecma262#2155 Differential Revision: https://phabricator.services.mozilla.com/D101013

michaelficarra · 2021-07-21T22:24:29Z

              </td>
              <td>
-                The name under which the desired binding is exported by the module identified by [[ModuleRequest]]. *null* if the |ExportDeclaration| does not have a |ModuleSpecifier|. *"\*"* indicates that the export request is for all exported bindings.
+                The name under which the desired binding is exported by the module identified by [[ModuleRequest]]. *null* if the |ExportDeclaration| does not have a |ModuleSpecifier|. ~*~ indicates that the export request is for all exported bindings.


I would prefer to use something like ~all~ for this.

…tcampbell The "Arbitrary module namespace identifier names" spec PR allows to use "*" as a module export name, so we can no longer use that specific string to denote star-imports/exports. Probably the easiest way to work around this new restriction is to replace "*" with a nullptr string. Spec change: tc39/ecma262#2155 Differential Revision: https://phabricator.services.mozilla.com/D101013

ljharb added the editorial change label Aug 26, 2020

ljharb requested review from a team, bakkot, bmeck, michaelficarra and syg August 26, 2020 23:21

ljharb pushed a commit to ljharb/ecma262 that referenced this pull request Aug 26, 2020

Editorial: stop using strings for special values (tc39#2155)

a0f117f

This was extracted from tc39#2154 so it could land separately.

ljharb force-pushed the enumb branch from cfc0fb1 to a0f117f Compare August 26, 2020 23:21

ljharb mentioned this pull request Aug 26, 2020

Normative: Arbitrary module namespace identifier names #2154

Merged

devsnek reviewed Aug 26, 2020

View reviewed changes

Comment thread spec.html Outdated

ljharb pushed a commit to ljharb/ecma262 that referenced this pull request Aug 26, 2020

Editorial: stop using strings for special values (tc39#2155)

f4de09c

This was extracted from tc39#2154 so it could land separately.

ljharb force-pushed the enumb branch from a0f117f to f4de09c Compare August 26, 2020 23:32

ljharb pushed a commit to ljharb/ecma262 that referenced this pull request Aug 26, 2020

Editorial: stop using strings for special values (tc39#2155)

6322daa

This was extracted from tc39#2154 so it could land separately.

ljharb force-pushed the enumb branch from f4de09c to 6322daa Compare August 26, 2020 23:36

devsnek reviewed Aug 26, 2020

View reviewed changes

Comment thread spec.html Outdated

ljharb added a commit to ljharb/ecma262 that referenced this pull request Aug 26, 2020

Editorial: stop using strings for special values (tc39#2155)

38c4c8e

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb force-pushed the enumb branch from 6322daa to 38c4c8e Compare August 26, 2020 23:39

ljharb requested a review from devsnek August 26, 2020 23:40

devsnek approved these changes Aug 26, 2020

View reviewed changes

bmeck approved these changes Aug 27, 2020

View reviewed changes

michaelficarra reviewed Aug 27, 2020

View reviewed changes

Comment thread spec.html Outdated

ljharb added a commit to ljharb/ecma262 that referenced this pull request Sep 2, 2020

Editorial: stop using strings for special values (tc39#2155)

538e4ac

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb force-pushed the enumb branch from 38c4c8e to 538e4ac Compare September 2, 2020 21:55

ljharb added a commit to ljharb/ecma262 that referenced this pull request Sep 2, 2020

Editorial: stop using strings for special values (tc39#2155)

9d1caea

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb force-pushed the enumb branch from 538e4ac to 9d1caea Compare September 2, 2020 21:58

ljharb requested a review from michaelficarra September 2, 2020 21:59

ljharb added a commit to ljharb/ecma262 that referenced this pull request Sep 2, 2020

Editorial: stop using strings for special values (tc39#2155)

e8f3b45

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb force-pushed the enumb branch from 9d1caea to e8f3b45 Compare September 2, 2020 22:05

michaelficarra approved these changes Sep 2, 2020

View reviewed changes

ljharb added a commit to ljharb/ecma262 that referenced this pull request Sep 2, 2020

Editorial: stop using strings for special values (tc39#2155)

b73e4ce

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

ljharb force-pushed the enumb branch from e8f3b45 to b73e4ce Compare September 2, 2020 23:39

ljharb requested a review from a team September 2, 2020 23:42

ljharb self-assigned this Sep 2, 2020

bakkot reviewed Sep 8, 2020

View reviewed changes

bfarias-godaddy and others added 3 commits September 7, 2020 22:22

Editorial: stop using strings for special values (tc39#2155)

dda632e

This was extracted from tc39#2154 so it could land separately. Co-authored-by: Jordan Harband <ljharb@gmail.com>

fixup! Editorial: stop using strings for special values (tc39#2155)

158950a

fixup! Editorial: stop using strings for special values (tc39#2155)

870e5f7

ljharb force-pushed the enumb branch from b73e4ce to 870e5f7 Compare September 8, 2020 05:22

bakkot reviewed Sep 8, 2020

View reviewed changes

lukewagner mentioned this pull request Oct 26, 2020

Security concern when importing executable modules as non-executable data WebAssembly/esm-integration#40

Closed

ljharb force-pushed the master branch 3 times, most recently from 3d0c24c to 7a79833 Compare June 29, 2021 02:21

michaelficarra reviewed Jul 21, 2021

View reviewed changes

syg added the editor call to be discussed in the next editor call label Oct 25, 2021

bakkot mentioned this pull request Nov 4, 2021

Editorial: mostly stop using strings for special values #2566

Merged

ljharb closed this in #2566 Nov 5, 2021

ExE-Boss mentioned this pull request Nov 8, 2021

Update and unflag “Arbitrary Module Namespace Identifier Names” engine262/engine262#182

Merged

bakkot removed the editor call to be discussed in the next editor call label Nov 10, 2021

ljharb deleted the enumb branch January 26, 2022 18:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Editorial: stop using strings for special values#2155

Editorial: stop using strings for special values#2155
ljharb wants to merge 3 commits into
tc39:mainfrom
ljharb:enumb

ljharb commented Aug 26, 2020

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bakkot commented Sep 8, 2020

Uh oh!

bakkot Sep 8, 2020

Uh oh!

bakkot Sep 8, 2020

Uh oh!

ljharb Sep 8, 2020

Uh oh!

ljharb commented Sep 8, 2020

Uh oh!

bakkot Sep 8, 2020 •

edited

Loading

Uh oh!

bakkot Sep 8, 2020

Uh oh!

michaelficarra Jul 21, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

	1. If _resolution_ is null or ~ambiguous~ throw a SyntaxError exception.
	1. If _resolution_ is null or ~ambiguous~, throw a SyntaxError exception.

Conversation

ljharb commented Aug 26, 2020

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bakkot commented Sep 8, 2020

Uh oh!

bakkot Sep 8, 2020

Choose a reason for hiding this comment

Uh oh!

bakkot Sep 8, 2020

Choose a reason for hiding this comment

Uh oh!

ljharb Sep 8, 2020

Choose a reason for hiding this comment

Uh oh!

ljharb commented Sep 8, 2020

Uh oh!

bakkot Sep 8, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bakkot Sep 8, 2020

Choose a reason for hiding this comment

Uh oh!

michaelficarra Jul 21, 2021

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

bakkot Sep 8, 2020 •

edited

Loading