no-unmodified-loop-condition: Inconsistent behavior in calling function on loop condition var depending on whether condition checks member or not

What 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:

1. 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() or toString() call.
2. 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.

[anseki]

@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.

[mysticatea]

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. 😦

const i = {value: 0, valueOf() { return ++this.value; }};
while (i < 10) {
    console.log(i);
}