tc39/proposal-string-matchall
ES Proposal, specs, tests, reference implementation, and polyfill/shim for String.prototype.matchAll
MIT
Issues
- 10
Path to Stage 4!
#21 opened by ljharb - 22
Committee feedback: fallback behavior
#39 opened by ljharb - 3
The 2nd argument to String.prototype.matchAll
#40 opened by kanasimi - 30
Re-evaluate IsRegExp call in MatchAllIterator?
#34 opened by ljharb - 4
Reduce indirections and calls with side-effects to make it easier to achieve a reasonable baseline performance?
#32 opened by anba - 6
Spec reviewer signoff
#22 opened by ljharb - 0
Spec editor signoff
#23 opened by ljharb - 6
Should the string case be global?
#30 opened by littledan - 8
Naming discussion
#26 opened by schuay - 7
- 5
Inconsistencies to RegExp.prototype[@@match]
#28 opened by schuay - 3
"matchAll" connotes including overlapping matches
#19 opened by ljharb - 7
Specification is unnecessarily defensive
#18 opened by littledan - 1
Add FAQ?
#25 opened by mathiasbynens - 1
Tests?
#24 opened by mathiasbynens - 2
Use a regex flag "y+" instead of an API method?
#20 opened by ljharb - 12
- 0
Create Symbol.matchAll
#2 opened by ljharb - 0
Allow String→RegExp coercion
#3 opened by ljharb - 1
Review notes
#4 opened by anba - 3
Expose `lastIndex` from iterator
#7 opened by RReverser - 22
Naming of the method
#8 opened by abozhilov - 10
Always start from the beginning of string
#5 opened by RReverser - 2
Should we have a Symbol.matchAll?
#14 opened by littledan - 12
Include offsets in return value
#13 opened by SebastianZ - 1
Proposition following exactly RegExp.prototype.exec
#12 opened by caub - 1
Support flag `/y`?
#11 opened by rauschma - 1
Readme: example + an FAQ
#10 opened by rauschma - 3
Should CreateRegExpStringIterator abstract operation list arguments in a signature?
#1 opened by ljharb