WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

Conversation

@lucacasonato
Copy link
Member

@lucacasonato lucacasonato requested a review from a team as a code owner February 18, 2025 21:33
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally seems good overall

@lucacasonato lucacasonato requested a review from ljharb February 18, 2025 22:17
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for Symbol.match, what about new RegExp?

@lucacasonato
Copy link
Member Author

The normative PR does not change the behaviour of the regexp constructor. It already only gets %Symbol.match% for objects (see https://tc39.es/ecma262/#sec-isregexp).

@ljharb
Copy link
Member

ljharb commented Feb 18, 2025

aha, then the normative PR has an even stronger case in favor of it :-)

@Ms2ger Ms2ger changed the title Add tests for not calling WK symbols on primitives for string methods Add tests for not calling well-known symbols on primitives for string methods Feb 19, 2025
Copy link
Contributor

@ptomato ptomato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems good. Any value for implementations in being exhaustive and adding tests for Symbol primitives as well? I'm leaning towards no.

@lucacasonato
Copy link
Member Author

Agree

@ptomato ptomato force-pushed the dont_call_wellknown_for_primitives branch from 85a4d36 to 2e5808e Compare March 12, 2025 00:50
@ptomato
Copy link
Contributor

ptomato commented Mar 12, 2025

The normative change has consensus and there were no further comments from implementations. I think we should merge this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants