Bring Dart's RegExp support in line with JavaScript: lookbehinds, property escapes, and named groups.

[gspencergoog]

So, it appears that JavaScript now does support positive lookbehinds (e.g. "(?<=foo)"), Unicode property escapes (i.e. "\\p{Greek}"), and named capture groups (e.g. "(?<foo>.*)"), at least according to the next release of the ECMA-262 specification. They are already supported in Chrome 64 and later.

https://github.com/tc39/proposal-regexp-named-groups
https://github.com/tc39/proposal-regexp-lookbehind
https://github.com/tc39/proposal-regexp-unicode-property-escapes

Unfortunately, the Dart VM/AOT compiler version of RegExp (i.e. when not compiled to JS) doesn't seem to support them, so the statement "Dart regular expressions have the same syntax and semantics as JavaScript regular expressions" isn't really true anymore. Some regular expressions work on Dartpad, but not in Flutter, for instance.

Dart should implement these too: they're also super useful.

[lrhn]

We have a discrepancy now. Dart compiled for the web does support these features, native Dart (including Flutter) does not. It's possible for people to write libraries, e.g., using DDC, that are intended to be portable, but which fail when used on Flutter.

There have been stack-overflow answers suggesting look-behind, and they even tested it in dartpad first. I can't fault them, but it's not a valid answer for a Flutter question.

We should address this in some way. Either:

• Say that it's deliberate, and do nothing. Web users get to use the full power of ECMAScript RegExps.
• Make a plan to update the VM RegExp engine.
• Do something to catch VM-invalid RegExps in browser code (e.g., a debug-mode only syntax check).

Since most RegExps are string literals, the analyzer can already now warn if a RegExp is not a valid ES5.1 RegExp.

[gspencergoog]

Also, with the announcement of Hummingbird, the story gets even more muddled: someone could implement a full working Flutter example and even share a link to it on SO, and be confused as to why it fails on Flutter when compiled for mobile.

Yes, there could be an analyzer check that warns users building for mobile that they can't use features meant for the web, but that feels like more of an excuse than a real solution.

I think this fractures Flutter's "write once, run anywhere" magic that Dart powers so well for virtually everything else.

[mit-mit]

Just to clarify: We have announced Hummingbird as an experimental project, not as an officially complete & supported product.

But, yes, we'll need to work through this problem, and resolve it to preserve good compatibility across our various host targets.

[mit-mit]

moving to @kevmoo to track Hummingbird requirements. Maybe we need a label for these.