RegExps that don't modify global state?

Andrea Giammarchi andrea.giammarchi at
Wed Sep 17 00:58:22 PDT 2014

On Wed, Sep 17, 2014 at 6:35 AM, Steve Fink <sphink at> wrote:
> Is
>   if ((m = /foo:(\d+)/.exec(str)) && parseInt(m[1], 10) > 15) { ... }
> so bad?

well, you just polluted the global scope "by accident" creating (maybe) a
hybrid Array with properties attaches in order to just access index 1 where
same array needs to be evaluated as truthy in the initial `if`


using a boolean value for an `if` statement and eventually access directly

which one would you pick?

> The global state *is* bad, and you don't need turns or parallelism to be
> bitten by it.
> function f(s) {
>   if (s.test(/foo(\d+/)) {
>     print("Found in " + formatted(s));
>     return RegExp.$1; // Oops! formatted() does a match internally.
>   }
> }

I don't think that's a real-world code example and I've personally never
done anything like that .. the case for `.test()` or
`` **is** to instantly access `RegExp` later on.

This does not play well with generators or with functions call in the
middle but it does not have to, it's straight forward for its use case that
has worked together until now and for 12+ years.

However, this summarizes even better my thoughts on proposing such change
through `/u`

> Unicode flag disabling features to enable parallelism is another footnote
for WTFJS.

new language features shouldn't be abused to sneakily drop well known
functionalities, regardless what I smoke.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list