Closed jfmengels closed 1 year ago
Very minor:
For all the errors that don't provide fixes because of the possibility of NaN
, it might make sense to add a reminder that the |> Simplify.expectNaN
configuration is active and that a fix is only suggested when this setting isn't added.
For all the errors that don't provide fixes because of the possibility of NaN, it might make sense to add a reminder that the
|> Simplify.expectNaN
configuration is active and that a fix is only suggested when this setting isn't added.
If I'm not mistaken, for all the places that care about NaN
the error is disabled, not just the fix. But I agree that we should probably mention the configuration if we only skip the fix.
New opt-in configuration option
expectNaN
which will disable some simplifications when the user indicates their project is likely to useNaN
values. This disables the following simplifications:x == x
toTrue
List.member x [ x ]
toTrue
n * 0
to0
When
expectNaN
is not used,n * 0
to0
will be reported (as before) but will now have an autofix.I may have missed other places where
NaN
could be a problem. This will enable working on https://github.com/jfmengels/elm-review-simplify/issues/41 safely.PR can be reviewed commit by commit.