New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normative: Remove implementation-defined typeof behavior #1441

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
6 participants
@littledan
Copy link
Member

littledan commented Feb 7, 2019

Previously, the ECMAScript specification permitted non-callable
non-standard exotic objects to have implementation-defined typeof,
within certain limits. Although some ECMAScript implementations
may have taken advantage of this possibility historically, it's not
clear that anyone needs it anymore. Instead, other mechanisms can
be used by embedders to indicate aspects of objects.

Closes #1440

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Feb 7, 2019

Pretty hard to test a lack of unknown implementation-defined behavior here, so I don't think this would need any tests :-)

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Feb 7, 2019

I'm wondering about the "needs consensus" label here. Do you think this needs to be presented at a TC39 meeting, or could we get consensus for it on GitHub?

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Feb 7, 2019

Generally, every normative change requires committee approval; it certainly seems like something we could decide on GitHub, but I would be uncomfortable merging a non-bugfix normative change without that explicit consensus.

@allenwb

This comment has been minimized.

Copy link
Member

allenwb commented Feb 8, 2019

Instead, @@toStringTag and other
mechanisms can be used by embedders to indicate aspects of objects

Just wanted to remind that @@toStringTag, unlike typeof, is forgeable and was never intended to be used as a reliable type checking mechanism. We shouldn't encourage people to try to use it that way.

Otherwise, I like the change this issue is proposing.

@annevk
Copy link
Member

annevk left a comment

You should also remove the note below the table as it's no longer applicable.

Normative: Remove implementation-defined typeof behavior
Previously, the ECMAScript specification permitted non-callable
non-standard exotic objects to have implementation-defined typeof,
within certain limits. Although some ECMAScript implementations
may have taken advantage of this possibility historically, it's not
clear that anyone needs it anymore. Instead, other mechanisms can
be used by embedders to indicate aspects of objects.

Closes #1440

@littledan littledan force-pushed the littledan:simplify-typeof branch from 20fee9e to 017ca29 Feb 9, 2019

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Feb 9, 2019

Removed the reference to @@toStringTag as @allenwb suggested and the note that @annevk pointed out. Thanks for the quick reviews everyone!

To the editor group: Do you plan to put this on the agenda for the upcoming TC39 meeting, or should I do it?

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Feb 9, 2019

It’s always preferred when committee members can drive their own needs-consensus changes.

@ljharb

ljharb approved these changes Feb 9, 2019

@ljharb ljharb requested review from bterlson , zenparsing and tc39/ecma262-editors Feb 9, 2019

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Feb 9, 2019

Alright, thanks for the clarification and quick review.

@jmdyck

This comment has been minimized.

Copy link
Collaborator

jmdyck commented Feb 10, 2019

It’s always preferred when committee members can drive their own needs-consensus changes.

So what should happen when a needs-consensus change doesn't 'belong' to a committee member?

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Feb 10, 2019

@jmdyck in that case (or when no committee member is driving it) it's up to the editors to proactively add it to the agenda, as time permits.

@jmdyck

This comment has been minimized.

Copy link
Collaborator

jmdyck commented Feb 10, 2019

Cool, thanks.

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