Consider removing internal slots from GetIndices

[schuay]

GetIndices is currently specified as a builtin function with internal slots [[InputString]], [[MatchIndices]], [[MatchIndicesArray]]. This requires allocation of a new function for each regexp result object.

Have you considered adding any required slots to the results object instead, and looking them up from the receiver when GetIndices is called?

cc @joshualitt @mathiasbynens

[rbuckton]

I have no issue with modifying the proposal if it becomes necessary to do so. I authored GetIndices in this way as the ECMAScript spec had readily available mechanisms for defining a built-in function in this fashion. @ljharb, @bterlson: Do you have any thoughts on this approach?

[ljharb]

If there’s not a new function for each result object, then it’s either frozen or a global communications channel. We’ve typically provided new functions each time rather than sharing a global frozen function.

[ljharb]

(Another alternative is a prototype method that looks up slots, but that’s not available for match objects since they’re normal arrays)

[joshualitt]

Unfortunately, creating a new closure for each result object will add overhead to every regexp.exec call, regardless of whether or not indices are actually used. If we go with the global frozen function, then indices are nearly free unless they are used. Does it make sense to weigh efficiency concerns here?

EDIT: Actually maybe I misspoke and we can wrap the result in a closure lazily. Still might be worth considering the additional cost of the per result closure.

[ljharb]

Additionally, if the slots are on the match object, it makes the object exotic - as currently specified, it’s just the getter function that has special behavior, and the match object remains ordinary.

[syg]

What was the motivation for reflecting the laziness of .indices in the spec itself? The root of the problem to me here is that reflection created an observable thing (i.e. that the .indices property descriptor is now a getter with different identity for each results object) that ties implementations' hands. I would much rather prefer it to be a vanilla data property and the array created eagerly in spec. An implementation can still choose to lazily allocate the array.

[rbuckton]

If implementers believe it should just be a data property then I'm fine with the change. The goal was to avoid the upfront penalty for initializing the value given the previous reticence towards possibly negatively impacting all existing RegExp uses.

[syg]

Sounds good. I'll draft a PR soon.

[rbuckton]

Fixed by #31