-
Notifications
You must be signed in to change notification settings - Fork 12
Consider removing ..
and __
from class-set reservations
#60
Comments
About the double-punctuation operators: They allow the use of single characters as literals as before, and they visually stand out. (Plus, there is precedent from some other regex engines.) Note that in a character class (=a set) there is no good reason for why someone would want to use any literal character more than once. More generally, we want to reserve syntax for future extensions, so that hopefully we don't need to add another flag for future regex features. We could quibble about allowing a literal We should lean towards reserving more than what seems likely useful now. Later, when a real desire for certain literals emerges, we could un-reserve and re-allow certain literals. |
That quibbling is an accurate description of this issue. The case for not reserving Bottom line: to subject either to special treatment inside a character class, even if that special treatment is limited to requiring escaping when repeated (which probably would never be written by hand, but could conceivably be the product of automated code generation), would be so surprising that it should be explicitly rejected by removing |
I am not convinced that allowing literal However, I could live with not treating these two as special. Note that Unicode Character Database files use |
I personally don’t feel strongly about
|
Meeting discussion: Richard feels strongest about the @waldemarhorwat What do you think about this issue? Keep reserving double |
I'm ok with unreserving both of these.
|
I don't see any reason to reserve |
We simply reserved every ASCII punctuation/symbol character when doubled. There does not seem to be any reason to use or support doubled characters as literals, except for backward compatibility, and the new flag gives us the luxury to reserve these now in case someone wants to extend the character class syntax in the future. As discussed, if people feel strongly, we could un-reserve |
It's traditional within the family of programming languages that includes ECMAScript to treat As I mentioned, I have no opinion on |
Given the above discussion, how about resolving this as follows:
|
Resolved by merging mathiasbynens/ecma262#12. |
It is surprising to see
..
and especially__
reserved in tc39/ecma262#2418 . Both.
and_
are interpreted literally anywhere in any current regular expression character class, the former because square brackets specifically strip its special meaning and the latter because it is a completely nonspecial character that is valid anywhere inside the name of an identifier (i.e., it's not even treated as punctuation in the context of ECMAScript).A case could be made for
.
, although in practice it almost always gets special mention with respect to character classes (e.g., https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Character_Classes includes "Inside a character class, the dot loses its special meaning and matches a literal dot.") and[.]
is frequently used to match a literal.
. But I strongly recommend not introducing such special treatment for_
.The text was updated successfully, but these errors were encountered: