Looks like we have 2 LGTMs then, but @ljharb's wasn't properly registered since it's a comment.

I'm trying to multiply 9.700000042 and 1000000000 using the times method. It should show 9700000042 as the final result. But it's returning 9700000041.999998. please help.

:heavy_check_mark: Deploy Preview for redux-docs ready!

:hammer: Explore the source changes: c41102abdbe465dbdbed63b918b6b9fee77cc5ab

:mag: Inspect the deploy log: https://app.netlify.com/sites/redux-docs/deploys/60c6dcf227d4230008f3fca1

:sunglasses: Browse the preview: https://deploy-preview-4108--redux-docs.netlify.app

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit c41102abdbe465dbdbed63b918b6b9fee77cc5ab:

The links and CodeSandbox iframe in the "Todos w/ Flow" example are broken: https://redux.js.org/introduction/examples#todos-w-flow

The actual example files were removed in a previous commit: https://github.com/reduxjs/redux/commit/ebf125297430ce33ea7b21279445bbb935092ed8#diff-c590b3c924c35c2f241746522284e4709df490d73a38aaa7d6de4ed1eac2f546

This PR just removes the references to the now-deleted example.

https://github.com/mysticatea/ecma262/commit/757927687ee99e96e9e39a88f6122716cc3088f2

That may be a candidate to patch this issue.

1. Remove two passes parsing from 22.2.3.2.3 Static Semantics: ParsePattern ( patternText, u ). It parses the pattern with [+N] always. This should be no problem because there are no other differences than allowing named backreferences.
2. Add an Annex B section to extend 22.2.3.2.3 Static Semantics: ParsePattern ( patternText, u ) to introduce two passes parsing for backward compatibility about \k.

is that the "but not UnicodeIDContinue" in the spec?

Yes. Keep in mind that's only there for the non-Annex B grammar, i.e. the one which is not used in actual implementations. (The Annex B variant does not have that restriction.)

hm... is that the "but not UnicodeIDContinue" in the spec? i must have a bug in engine262

@devsnek That's right in Annex B. But it's a syntax error in the spec core because the sequence \ k is not allowed.

I think this is correct as specified. The first pass will parse \k<foo> as the atoms k < f o o >, not a syntax error.

Yes, it skips the second pass if the first pass had a syntax error, and \k in the first pass is a syntax error.

Maybe, should both the N parameter and two passes parsing move to Annex B? Those look to be for Annex B behaviors.

It's a syntax error on the first pass, I agree, but that means that it will re-parse with the N parameter set, and when parsing with the N parameter we have the production AtomEscape :: k GroupName, which matches \k<foo> as in this example. Since it parses successfully on the second pass, it's allowed.

<!-- Thank you for reporting a possible bug in ECMA-262.

If this is a bug with a specific implementation of ECMA-262, such as a JavaScript engine or a browser, please report it on their bug tracker instead.

eshost is a tool to run the same code on many JS engines to compare the output.

To set up eshost:

1. $ npm i -g eshost-cli jsvu
2. $ jsvu
3. $ eshost --configure-jsvu

Running eshost:

Use -x to evaluate multiple statements: $ eshost -s -x "const a = 1 + 1; print(a);"

Or -e to evaluate a single expression: $ eshost -s -e "1 + 1"

Paste the output of eshost into the box below. -->

Description: Adding 1 and 1 is two, but it should be...

From https://github.com/mysticatea/regexpp/issues/23.

This is about /(?<foo>A)\k<foo>/ without u flag and without Annex B.

• 22.2.3.2.3 Static Semantics: ParsePattern ( patternText, u ) says "if no u flag, parse the pattern without N parameter, then if no syntax errors exist and named capturing groups exist, re-parse the pattern with N parameter."
• \k is a syntax error if no N parameter and no Annex B.

As a result, named capturing groups without u flag are always a syntax error.

I think IdentityEscape requires [~N] k or something like that in order to allow named capturing groups with no u flag.

eshost Output:

(I'm not sure about the environment without Annex B)

It's still the case (as it has been since CreateBuiltinFunction was introduced) that if the function being created is an ordinary function object, CreateBuiltinFunction doesn't say how most of its internal slots are initialized. Without trying to 'fix' that shortcoming, we could maybe at least acknowledge it in a Note. E.g.:

NOTE: If func is an ECMAScript function object, it has many other internal slots that must be initialized, but this operation does not address how that happens.

With or without that, I think this PR is somewhat clearer than the status quo about internal slots of built-ins.