I think it would be more worthwhile of we tried to draw a compatibility
boundary. Taking perlre as a baseline, for example, are there additional
characters we should escape in `RegExp.escape` so that implementations (and
the language itself) could add more perlre features without breaking
On Jul 5, 2015, at 10:56 PM, Benjamin Gruenbaum wrote:
So, following work on RegExp.escape [1] I found out that implementations may
extend the regular expression grammar in JavaScript [2]. However, when asking
esdiscuss and Stack Overflow about it [2][3] it doesn't look like any
Hi Brian, ES-Discuss,
The SIMD.js spec and polyfill still lives in John McCutchan's GitHub
account. How can we transfer this to the TC39 account in accordance
with ECMA's requirements?
Thanks,
Dan
___
es-discuss mailing list
es-discuss@mozilla.org
This isn't really about `RegExp.escape` as an issue. We can always extend
`RegExp.escape` when we make additions to the RegExp grammar as a standard
that would not be a problematic issue since we can keep both parts in sync
relatively easily.
On the other hand currently implementations are
On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola d...@domenic.me wrote:
To be explicit: there is no way to look at a string of JavaScript text and
tell whether it should be treated as a module or a script. In many
instances the same string can be treated as both.
The decision is made by
5 matches
Mail list logo
