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

New Rule: prefer-exponentiation-operator #10482

Closed
RyanZim opened this issue Jun 15, 2018 · 13 comments · May be fixed by rsumner868/librealsense2.1#1, rsumner868/librealsense#4, O330oei/node#4 or O330oei/node#11
Closed

Comments

@RyanZim
Copy link

@RyanZim RyanZim commented Jun 15, 2018

Please describe what the rule should do:

ES2016 adds an exponentiation operator **; this may be preferred over using Math.pow(). The rule should disallow the use of the Math.pow() function, in favor of using **.

What category of rule is this? (place an "X" next to just one item)

[ ] Enforces code style
[ ] Warns about a potential error
[x] Suggests an alternate way of doing something
[ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

// Good
const a = 5 ** 7

// Bad
const a = Math.pow(5, 7)

Why should this rule be included in ESLint (instead of a plugin)?

This is a ES2016 feature, which can replace an older way of doing things. There should be a rule to force upgrading code; similar to how ESLint has no-var, prefer-spread, etc.

@eslint eslint bot added the triage label Jun 15, 2018
@ljharb
Copy link
Contributor

@ljharb ljharb commented Jun 15, 2018

Instead, this rule should probably be called prefer-exponentiation-operator? Then it could also apply to 2 * 2 * 2 :-p

@RyanZim
Copy link
Author

@RyanZim RyanZim commented Jun 15, 2018

@ljharb Good point, that would work too; though I don't know how common 2 * 2 * 2 is; IDK if it's worth building the logic for that.

@platinumazure
Copy link
Member

@platinumazure platinumazure commented Jun 15, 2018

This is currently doable using no-restricted-properties.

That said, I'm not opposed to a new rule for this case.

@ljharb
Copy link
Contributor

@ljharb ljharb commented Jun 15, 2018

It would be wonderful for the airbnb config to have a standalone rule rather than using no-restricted-properties.

@RyanZim
Copy link
Author

@RyanZim RyanZim commented Jun 15, 2018

I didn't think about no-restricted-properties; that is one solution, though it's easier to understand if there's a rule explicitly for it, and a dedicated rule could potentially support auto-fixing.

@mysticatea mysticatea self-assigned this Jun 22, 2018
@mysticatea
Copy link
Member

@mysticatea mysticatea commented Jun 22, 2018

I'll champion this proposal. I like the rule name prefer-exponentiation-operator and it has autofix. That rule will encourage to learn the new syntax.

@sindresorhus
Copy link
Contributor

@sindresorhus sindresorhus commented Jan 24, 2019

If anyone needs this rule, it's available in eslint-plugin-unicorn.

@ljharb
Copy link
Contributor

@ljharb ljharb commented Jan 24, 2019

@sindresorhus it'd be great if you PR'd it and its tests into eslint core :-)

@izayl
Copy link

@izayl izayl commented Feb 1, 2019

https://stackoverflow.com/questions/41679191/why-is-math-pow-sometimes-not-equal-to-in-javascript

According to this questions, use Math.pow() is safer than **.

@ljharb
Copy link
Contributor

@ljharb ljharb commented Feb 1, 2019

The comments suggests it’s just a bug in v8; not a reason to write code differently.

@mysticatea mysticatea changed the title New Rule: no-math-pow New Rule: prefer-exponentiation-operator Sep 25, 2019
@mdjermanovic mdjermanovic added accepted and removed evaluating labels Sep 25, 2019
@mdjermanovic
Copy link
Member

@mdjermanovic mdjermanovic commented Sep 25, 2019

👍 It's accepted now

I don't know is it relevant for the decision to implement the rule, but it seems that the bug hasn't been fixed yet:

https://bugs.chromium.org/p/v8/issues/detail?id=5848

@kaicataldo
Copy link
Member

@kaicataldo kaicataldo commented Sep 25, 2019

@mdjermanovic I don't think we should let a single runtime's bug prevent us from adding this rule, but it could be nice to include a link to the bug in the rule's docs.

@mdjermanovic
Copy link
Member

@mdjermanovic mdjermanovic commented Oct 1, 2019

I'm working on this.

From the specification, it seems that the only difference is when both arguments evaluate to bigint, as ** doesn't crash in that situation (it would crash if only one is bigint), unlike Math.pow.

Re the autofix, I think it's an acceptable change in behavior 👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.