Skip to content
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

Editorial: Use consistent phrasing for parameters that are Number or BigInt #2622

Merged
merged 1 commit into from
Apr 27, 2022

Conversation

gibson042
Copy link
Contributor

Before this change, NumericToRawBytes is the odd one out (it uses "a BigInt or a Number" while SameValueNonNumeric and SetValueInBuffer and GetModifySetValueInBuffer all use "a Number or a BigInt").

@michaelficarra
Copy link
Member

michaelficarra commented Jan 19, 2022

I introduce a few of these in #2547 (I add a ton of explicit AO return types). Can we hold off on merging this until we have an ecmarkup lint rule enforcing it so I don't just re-introduce these?

@michaelficarra michaelficarra added the editor call to be discussed in the next editor call label Jan 19, 2022
@michaelficarra michaelficarra removed the editor call to be discussed in the next editor call label Jan 19, 2022
@michaelficarra michaelficarra added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Apr 27, 2022
@ljharb ljharb force-pushed the 2022-01-phrasing-consistency branch from f8f0103 to 8e64031 Compare April 27, 2022 22:07
@ljharb ljharb merged commit 8e64031 into tc39:main Apr 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial change establishes editorial conventions ready to merge Editors believe this PR needs no further reviews, and is ready to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants