Contact email
Explainer
https://github.com/tc39/ecma262/pull/1527#issuecomment-489228449
Spec
Contact email
Explainer
https://github.com/tc39/ecma262/pull/1527#issuecomment-489228449
Spec
SummaryReplace all early ReferenceErrors with early SyntaxErrors.MotivationThe spec has been inconsistent with respect to the "early ReferenceError" notion: only update/assignment expressions (e.g. `0++`, `0 = 0`) have had early ReferenceErrors, while other invalid assignment target cases like `[0] = []` and `for (0 of []) {}` have been early SyntaxError.Furthermore, this becomes an observable concern with eval: if eval throws a ReferenceError, the user has had no way to know whether the code was actually executed or simply parsed (short of matching on error message strings).RisksInteroperabilityNone. This reached consensus at TC39, it received explicit positive feedback from all major engines, and it is already shipping in Safari TP 83.CompatibilityNone expected. This simply changes a parse-time error type. As mentioned above, it would have been nearly impossible for userland code to depend on this typing.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes.Is this feature fully tested by Test262?Link to entry on the feature dashboardRequesting approval to ship?Yes.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHnZyqBi3XLxmrsCUVt1tcOirf4rQzz_RwzHh89%2B0zCk0B-e6w%40mail.gmail.com.
I don't expect to see code that special cases against ReferenceError
in the wild especially for just early errors. I expect to see code
that handles both ReferenceErrors and SyntaxErrors. Since we're not
adding a new type of error, I wouldn't expect to see any breakage.
The concern here is purely around *early* ReferenceError. Since ReferenceError has been ambiguous between parse time and runtime, it would have been extremely difficult/fragile to use this information—as mentioned, one would need to string-match on error messages. (I think folks are hung up on the phrase "observable concern", but I meant this to indicate that there's something non-cosmetic to be *gained*, not that there's worry about breakage.)The new behavior shipped in Safari TP 83 three weeks ago, and it's important to note that the major engines were not previously in alignment anyway. V8 was conforming to spec, but JSC actually had *late* ReferenceError for all four cases and SM was split (`0++` and `0--` were early SyntaxError while `0 = 0` and `0 += 0` were early ReferenceError).
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhQtWJoxxi3PwfutmSbZFJGyNkKpgD1OeMFDM6%3D2sA4bw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhQtWJoxxi3PwfutmSbZFJGyNkKpgD1OeMFDM6%3D2sA4bw%40mail.gmail.com.
--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAEvLGcKV93MirncPshaX9z29%3D5-0aBcecEOJ-Z%3D0zZE1%2BQb%3D7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Is this feature controlled by a flag.I try to roll test262 and got a lot of errors related to this now.
Hi Yoav,We don't have existing metrics that would help here, and I honestly don't even know what we would track for this specific issue (detecting that a certain exception came from eval, for example, isn't something we currently track).Bug reports are how we tend to track issues like this. And fwiw my intuition matches Sathya & Ross's (that this is very unlikely to cause problems in practice).
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcKV93MirncPshaX9z29%3D5-0aBcecEOJ-Z%3D0zZE1%2BQb%3D7w%40mail.gmail.com.
On Wed, Jun 19, 2019 at 9:07 PM Adam Klein <ad...@chromium.org> wrote:Hi Yoav,We don't have existing metrics that would help here, and I honestly don't even know what we would track for this specific issue (detecting that a certain exception came from eval, for example, isn't something we currently track).Bug reports are how we tend to track issues like this. And fwiw my intuition matches Sathya & Ross's (that this is very unlikely to cause problems in practice).OK. Do you typically get those bug reports on Canary, Beta, or once the feature in question have hit stable?(This is more of a generic question: I don't think this particular feature should block on putting counters in place if this is how V8 typically rolls. I just want to better understand your workflow regarding deprecations and changes)