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

[petamoriken]

Fixed that methods for RegExp, such as %Symbol.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

Test262

• Add tests for not calling well-known symbols on primitives for string methods test262#4404

Implementations

• V8: https://issues.chromium.org/issues/451217461
• JavaScriptCore: [JSC] Don't get RegExp well-known symbol methods for primitives WebKit/WebKit#43240
• SpiderMonkey: https://bugzilla.mozilla.org/show_bug.cgi?id=1998177
• LibJS: LibJS: Update to normative change to avoid Symbol methods for RegExp on primitives LadybirdBrowser/ladybird#4619

[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.

[ljharb]

Where has this change been implemented?

[michaelficarra]

@ljharb The OP lists 3 implementations.

[ljharb]

awesome, thanks :-)

[petamoriken]

This Normative Change has been implemented in all major engines and released with Chrome 143. It might be good to merge it.