This repository has been archived by the owner on Jan 26, 2022. It is now read-only.
Path to Stage 4! #21
Comments
|
@ljharb FYI - an initial V8 implementation has landed (behind a flag) https://chromium-review.googlesource.com/c/v8/v8/+/981893 |
This comment has been minimized.
This comment has been minimized.
|
It's implemented in core-js now |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
mathiasbynens
added a commit
to mathiasbynens/proposal-string-matchall
that referenced
this issue
Aug 8, 2018
@anba outlined two separate concerns about the remaining `IsRegExp` call in `MatchAllIterator`. Quoting from tc39#34 (comment): 1. When `MatchAllIterator` is called from `RegExp.prototype [ @@matchall ]`, we should/have to assume the user explicitly decided to treat `R` as a RegExp object, so having an additional `IsRegExp` call to change this decision seems questionable. It’s also not consistent with how the other `RegExp.prototype` methods work. 2. When `MatchAllIterator` is called from `String.prototype.matchAll`, I’d prefer to handle it more like the other `String.prototype` methods which create RegExp objects (that means `String.prototype.match` and `String.prototype.search`), because I want to avoid adding yet another way to handle RegExp sub-classes. There are already two different RegExp sub-classing/extension interfaces: the `RegExp.prototype` methods all call `RegExpExec`, which means sub-classes, or any other classes, only need to provide their own `exec` methods when they want to reuse the other `RegExp.prototype` methods. And in addition to that, the `@@match/replace/search/split` interfaces allow sub-classes to provide their own implementations for just these methods. The `matchAll` proposal in its current form adds another dimension to this by providing different code paths depending on whether or not an object is RegExp-like (as per the `IsRegExp` abstract operation). In my opinion we should only support RegExp sub-classing in two ways: 1) Either the RegExp sub-class has `%RegExpPrototype%` on its prototype chain, or 2) the RegExp sub-class copies the relevant methods from `%RegExpPrototype%` into its prototype object. Ref. tc39#21, tc39#34.
This comment has been minimized.
This comment has been minimized.
ljharb
added a commit
that referenced
this issue
Aug 8, 2018
- `String.prototype.matchAll`: - use `RegExpCreate` when `Symbol.prototype.matchAll` is not found - fall back to regex coercion otherwise - `RegExp.prototype[Symbol.matchAll]`: - receiver is assumed to be a regex implicitly - remove `MatchAllIterator` abstract operation Thus, `IsRegExp` call no longer exists. Addresses #21. Addresses #34. Closes #37.
ljharb
added a commit
that referenced
this issue
Aug 9, 2018
- `String.prototype.matchAll`: - use `RegExpCreate` when `Symbol.prototype.matchAll` is not found - fall back to regex coercion otherwise - `RegExp.prototype[Symbol.matchAll]`: - receiver is assumed to be a regex implicitly - remove `MatchAllIterator` abstract operation Thus, `IsRegExp` call no longer exists. Addresses #21. Addresses #34. Closes #37.
This comment has been minimized.
This comment has been minimized.
|
It's unflagged in Firefox 67 now |
|
This proposal reached stage 4 at today's TC39, yay! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Stage 4Stage 3Stage 2The text was updated successfully, but these errors were encountered: