-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IdentifierPart is ambiguous re '_' ? #1059
Comments
This is correct: /\p{ID_Continue}/u.test('_');
// → true We can just drop the spec.html | 1 -
1 file changed, 1 deletion(-)
diff --git a/spec.html b/spec.html
index b552ed8..6b5339e 100644
--- a/spec.html
+++ b/spec.html
@@ -9813,7 +9813,6 @@
IdentifierPart ::
UnicodeIDContinue
`$`
- `_`
`\` UnicodeEscapeSequence
<ZWNJ>
<ZWJ> |
In that case please add a note: it would be confusing for a non-expert reader to see |
We could also make spec.html | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/spec.html b/spec.html
index b552ed8..a64ca7c 100644
--- a/spec.html
+++ b/spec.html
@@ -9811,10 +9811,8 @@
`\` UnicodeEscapeSequence
IdentifierPart ::
+ IdentifierStart
UnicodeIDContinue
- `$`
- `_`
- `\` UnicodeEscapeSequence
<ZWNJ>
<ZWJ> |
... because that RHS made it ambiguous. (Resolves issue tc39#1059.)
With that, |
It seems to me that the simplest way to eliminate this ambiguity is: UnicodeIDContinue :: |
... because that RHS made it ambiguous. (Resolves issue tc39#1059.)
... because that RHS made it ambiguous. (Resolves issue tc39#1059.)
... because it's already derived by UnicodeIDContinue RHS. (See issue tc39#1059.)
... because that RHS made it ambiguous. (Resolves issue #1059.)
... because it's already derived by UnicodeIDContinue RHS. (See issue #1059.)
Yup, thanks. |
As I understand it,
'_'
(U+005F LOW LINE) belongs to Unicode general category 'Pc' (Connector_Punctuation), and so has the 'ID_Continue' property, and so matches the ECMAScript nonterminalUnicodeIDContinue
. This means thatIdentifierPart
derives'_'
in two distinct ways (viaUnicodeIDContinue
and via the'_'
literal), and so is technically ambiguous. I don't think this causes any semantic ambiguity (because the spec doesn't much care about howIdentifierPart
matches source text), but it's odd.The text was updated successfully, but these errors were encountered: