Normative: Don't call well-known Symbol methods for RegExp on primitive values

[petamoriken]

Fixed that methods for RegExp, such as @@split, are not called on primitive values.

Background

The internal code of runtimes such as Node.js and Deno are implemented that they work without problems even if they are polluted with prototypes. With this normative change in place, those runtimes don't need to worry if changes to String.prototype[Symbol.split] are polluted.

On the other hand, if this normative change is not approved, the following workaround will have to be provided:

// primordial
const StringPrototypeSplit = Function.call.bind(String.prototype.split);

// safe wrapper
export const SafeStringPrototypeSplit = (str, separator, limit) => {
  if (typeof separator === "string") {
    return StringPrototypeSplit(str, {
      __proto__: null,
      toString() { return separator },
    }, limit);
  }
  return StringPrototypeSplit(str, separator, limit);
};

This approach could cause performance issue.

downstream: denoland/deno#17473

[ljharb]

@petamoriken can someone from deno add this to the March meeting agenda?

[petamoriken]

@lucacasonato Would you work on this issue?

[bathos]

I can see that this change would cause this to no longer evaluate to “surprise”:

String.prototype[Symbol.split] = () => "surprise";
"a.b.c".split(".");

I see no obvious downside to the proposed change in a vacuum, but given it’s a breaking change, I’m curious whether there’s been research yet on whether it’s web compatible in practice?

(It seems plausible that it could be safe, but it also seems plausible that faithful polyfill implementations, e.g. @zloirock’s core-js, could be impacted).

[zloirock]

core-js does not detect delegation to @@methods for primitives, only for objects, so it's enough safe.

[erights]

The (typeof separator === "string") in the expository shim should instead be
(!isObject(separator)) assuming

const isObject = v => Object(v) === v;

[ptomato]

Test262 PR has landed.