no-unmodified-loop-condition: Inconsistent behavior in calling function on loop condition var depending on whether condition checks member or not
See original GitHub issueWhat version of ESLint are you using?
2.5.3
What parser (default, Babel-ESLint, etc.) are you using?
default
Please show your full configuration:
{
"rules": {
"no-unmodified-loop-condition": "error"
}
}
What did you do? Please include the actual source code causing the issue.
Example 1:
for (var i = []; i != 0; i.push(0)) {
}
Example 2:
for (var i = []; i.length === 0; i.push(0)) {
}
What did you expect to happen?
Both examples feature the loop condition being modified, via a function call on the object that has side effects. I would expect neither to result in a lint error.
What actually happened? Please include the actual, raw output from ESLint.
Example 1 (where the condition variable is directly compared) results in a lint error:
1:18 - ‘i’ is not modified in this loop (no-unmodified-loop-condition)
Example 2 (where a property of the condition variable is compared) has no errors.
My take on this is as follows:
- If we call a function on an object, it can have side effects on the object and should count as a modification.
a. A direct comparison with a number or a string could be taking advantage of a
valueOf()
ortoString()
call. - It shouldn’t matter whether we’re checking the variable itself or a property of the variable when evaluating whether a condition is modified.
But perhaps there’s an overarching design I’m not aware of which would explain the reasoning here?
Also, my original use case used Moment.js and is less stupid-looking than Example 1. I created my examples to prove that the library didn’t matter.
Original use case:
for (var weekCursor = weekStartDate.clone().add("weeks", 1); weekCursor <= weekEndDate; weekCursor.add("weeks", 1)) {
that._addEventForWeek(weekCursor, event);
}
Where weekCursor.add("weeks", 1)
is a function that has side-effects for the object on which it’s called.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:7 (5 by maintainers)
@mysticatea I’m sorry, I used v2.2.0 for the code above. I tried that with v2.8.0, then those messages are not shown. I am sorry for the lack of confirmation.
Honestly, I hadn’t noticed that simple comparisons can have side effects. I think we should describe
valueOf
,toString
, and[Symbol.toPrimitive]
as known limitations in the document of this rule.No longer I can believe comparisons in JS. 😦