You can clone with
HTTPS or Subversion.
The indexOf utility fallback doesn't follow spec enough in regards to sparse arrays.
Instead of hasOwnProperty the in operator should be used.
See this and this.
Agreed. @satyr's implementation looks good to me, but with one concern: I'm wondering if we should use the Strict Equality Comparison Algorithm like indexOf or an egal comparison. Since it's an operator of our own design, I think we have the freedom to use egal, so I'd prefer that. NaN in [NaN] producing false and -0 in  producing true is a little unexpected.
NaN in [NaN]
-0 in 
Input from @jashkenas is needed here.
I think @satyr's implementation looks good. I think I would expect triple equals semantics ... as nothing else in the language has egal semantics, and you'd expect in to work analogously to is.
fixes #1771: indexOf utility and comprehensions should use `in` seman…
not hasOwnProperty tests as in the indexOf utility or no test as in the
fix for #1771 fix: only do the check on list comprehensions, not objects
Support for sparse arrays in IE isn't worth the tradeoff of adding an extra in -- CoffeeScript comprehensions are supposed to compile to vanilla for loops. Closing as a wontfix.
By not having the indexOf utility follow spec you have inconsistent behavior for IE < 9 (and any other browser without native indexOf) vs browsers with native Array#indexOf.
The array comprehension issue isn't an IE issue.
It's to align with ES.Next and existing JS comprehension implementations.
The cost in the indexOf utility is probably a wash as you would be removing the incorrect hasOwnProperty check and replacing it with the in check.
Yes -- the in change is fine, and has been committed (although I don't see it listed here yet), but adding an in to every iteration through a comprehension -- which is what the pull request was doing, isn't a change we want to make.
Fixes #1771: Fixing the indexOf shim.