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

Rule Request: Forbid NaN comparison #2086

Closed
2 tasks done
guilhermearaujo opened this issue Mar 7, 2018 · 0 comments · Fixed by #3089
Closed
2 tasks done

Rule Request: Forbid NaN comparison #2086

guilhermearaujo opened this issue Mar 7, 2018 · 0 comments · Fixed by #3089
Labels
rule-request Requests for a new rules.

Comments

@guilhermearaujo
Copy link

New Issue Checklist

Rule Request

Instances of FloatingPoint (eg Float, Double, CGFloat, etc) should not be compared to a NaN using equal-to or not-equal-to operators. Doing so will result in unwanted or unpredicted behaviour, as comparisons using these operators will always return false and true, respectively.

  1. Why should this rule be added? Share links to existing discussion about what
    the community thinks about this.

Apple docs on FloatingPoint.isNaN:

Because NaN is not equal to any value, including NaN, use this property instead of the equal-to operator (==) or not-equal-to operator (!=) to test whether a value is or is not NaN.

StackOverflow discussion on IEEE Standard 754 (quoting the Standard)

Four mutually exclusive relations are possible: less than, equal, greater than, and unordered. The last case arises when at least one operand is NaN. Every NaN shall compare unordered with everything, including itself.

  1. Provide several examples of what would and wouldn't trigger violations.

Would trigger

if myFloating == .nan { ... }  // Same as `if false`
if myFloating != .nan { ... }  // Same as `if true`
if myFloating >= .nan { ... }  // Same as `if false`
if myFloating < .nan { ... }   // Same as `if false`
// Etc.

Would NOT trigger

if myFloating.isNaN { ... }
if !myFloating.isNaN { ... }
  1. Should the rule be configurable, if so what parameters should be configurable?
    I can't think of any.

  2. Should the rule be opt-in or enabled by default? Why?
    Enabled by default, because comparing, for instance, a Double to Double.nan will always return false. This can cause the program to have an undesired behaviour. The correct way is to check the isNaN property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule-request Requests for a new rules.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants