I vote for removing this.

What would the compatibly issues be? Code would get `undefined` instead of `false` when read.

I have a hard time imagining us making this property actually do anything.

At the moment it is compatible with Safari:

re = /foo/m

re.multiline // true

re2 = /foo/

re2.multiline // false

This thread is about RegExp.multiline, the "static" accessor of the RegExp object (https://github.com/v8/v8-git-mirror/blob/299b369cc950e221389eb4c585128c55155f9bc1/src/regexp.js#L389-L405).

The implementation is compatible with V8, but not compatible with SpiderMonkey, and it's not really doing anything useful (as this global state is not used anywhere)

Er, the implementation in V8 is compatible with JSC* =)

erikcorry: This bug is about removing RegExp.multiline, not the multiline property on regexp instance objects.

re = /foo/m

RegExp.multiline // false

re2 = /foo/

RegExp.multiline // false


In fact, the internal global value RegExp.multiline setter sets is not used anywhere except in the RegExp.multiline getter.

Chakra doesn't implement RegExp.multiline at all so the risk of web breakage due to removing it seems low. I vote for the axe!

Mozilla bug report for removing RegExp.multiline:
https://bugzilla.mozilla.org/show_bug.cgi?id=1219757

WebKit bug report for removing useless RegExp.multiline and RegExp['$*']:
https://bugs.webkit.org/show_bug.cgi?id=150714

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c49d0932397f08543b89e5b3dc7d537339ed8173

commit c49d0932397f08543b89e5b3dc7d537339ed8173
Author: caitpotter88 <caitpotter88@gmail.com>
Date: Sat Nov 07 00:44:54 2015

[LayoutTests] mark fast/js/regexp-caching.html as NeedsManualRebaseline

BUG=552574, v8:3870
LOG=N
R=yangguo@chromium.org, ojan@chromium.org

Review URL: https://codereview.chromium.org/1428393003

Cr-Commit-Position: refs/heads/master@{#358471}

[modify] http://crrev.com/c49d0932397f08543b89e5b3dc7d537339ed8173/third_party/WebKit/LayoutTests/TestExpectations

@brian.terlson: unfortunately it looks like Edge does implement the other non-standard flags :(

```
JSON.stringify([ "input", "multiline", "lastMatch", "lastParen", "leftContext", "rightContext", "$_", "$*", "$&", "$+", "$`","$'", "$1", "$2", "$3", "$4","$5", "$6", "$7", "$8", "$9"].reduce((p, c) => { p[c] = RegExp.hasOwnProperty(c); return p; }, {}), null, 2)
"{
  "input": true,
  "multiline": false,
  "lastMatch": true,
  "lastParen": true,
  "leftContext": true,
  "rightContext": true,
  "$_": true,
  "$*": false,
  "$&": true,
  "$+": true,
  "$`": true,
  "$'": true,
  "$1": true,
  "$2": true,
  "$3": true,
  "$4": true,
  "$5": true,
  "$6": true,
  "$7": true,
  "$8": true,
  "$9": true
}"
```

Maybe these need to be annex-B-ified, if they were added for web compat.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/e63248f6d75c7a155bc300ba847252b8f354d600

commit e63248f6d75c7a155bc300ba847252b8f354d600
Author: caitpotter88 <caitpotter88@gmail.com>
Date: Mon Nov 09 14:03:15 2015

[regexp] remove no-op RegExp.multiline accessor and alias

Remove some non-standard code that doesn't do anything anyways.

While FireFox uses this to set the default value for the multiline flag,
it is nonstandard and slated for removal. The matching behaviour has
never been implemented in either JSC or V8, so there is little
web-compat risk.

The only possible risk could be someone depending on the ToBoolean()
behaviour of the flag, but this seems unlikely.

BUG=v8:3870
LOG=N
R=adamk@chromium.org, littledan@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1417733012

Cr-Commit-Position: refs/heads/master@{#31882}

[modify] http://crrev.com/e63248f6d75c7a155bc300ba847252b8f354d600/src/js/regexp.js
[modify] http://crrev.com/e63248f6d75c7a155bc300ba847252b8f354d600/test/mjsunit/regexp-static.js
[modify] http://crrev.com/e63248f6d75c7a155bc300ba847252b8f354d600/test/mozilla/mozilla.status

This Issue seems resolved and should be closed...