You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Why should this rule be added? Share links to existing discussion about what
the community thinks about this.
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.
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.
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 {...}
Should the rule be configurable, if so what parameters should be configurable?
I can't think of any.
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.
The text was updated successfully, but these errors were encountered:
New Issue Checklist
Rule Request
Instances of FloatingPoint (eg
Float
,Double
,CGFloat
, etc) should not be compared to aNaN
using equal-to or not-equal-to operators. Doing so will result in unwanted or unpredicted behaviour, as comparisons using these operators will always returnfalse
andtrue
, respectively.the community thinks about this.
Apple docs on
FloatingPoint.isNaN
:StackOverflow discussion on IEEE Standard 754 (quoting the Standard)
Would trigger
Would NOT trigger
Should the rule be configurable, if so what parameters should be configurable?
I can't think of any.
Should the rule be opt-in or enabled by default? Why?
Enabled by default, because comparing, for instance, a
Double
toDouble.nan
will always returnfalse
. This can cause the program to have an undesired behaviour. The correct way is to check theisNaN
property.The text was updated successfully, but these errors were encountered: