Skip to content


Subversion checkout URL

You can clone with
Download ZIP


The `for-in` construct and the `in` operator #436

sethaurus opened this Issue · 7 comments

4 participants


In Javascript, for (x in y) and if(x in y) mean, respectively, "do this for every property of y," and "do this if y has a property named x".

In Coffeescript, for x in y and if x in y mean, respectively, "do this for every array element of y," and "do this if y has a property named x."

That is, in Coffeescript, the keyword in can refer to both array items and property names, depending on the context. This is somewhat inconsistent. Since Coffeescript already changes the meaning of the in operator in an iteration context, and introduces the of keyword for object-property iterations, it would make sense if we also used if x of y to mean "do this if y has an object-property named x."

The meaning of in has already been altered from its Javascript origins, so it would be consistent if its meaning as an infix operator matched its iteration meaning. Conversely, the current use of the of keyword could be expanded to take its place as a test of object-properties.

If we make this change, then if x in y could take on the meaning "do this if x is an array-element of y." This could potentially be compiled as follows:

# Coffeescript:
if x in y

// Javascript:
if ((function(){
    for (var i = 0; i < y.length; ++i) {
        if (y[i] === x) return true;
})()) {

# Coffeescript with array literal optimization:
if x in ['a', 'b', 'c']

// Javascript:
var _a;
if ((_a = x) === 'a' || _a === 'b' || _a === 'c') {

Or we could switch around the meanings of "on" and "of" in CS


Please forgive me for being obtuse, but how would switching of and on resolve the currently inconsistent meanings of the in keyword?


Sorry - i meant 'in' and 'of'


I think this is a beautiful idea, and it solves our recent issue about element-in-array-detection at a stroke.

I'd be glad to take a patch that implements sethaurus' proposal. Otherwise, I'll try to take a look at it later.


I agree, though this change will break some existing code. It is nicely consistent.


This change is now on master.

And is used in a couple places in the Rewriter:

Thanks much, sethaurus. Closing the ticket.


Didn't read this properly before. Isn't it odd if the behavior depends on if you have an implicit array (e.g. y) or an explicit array (e.g. ['a','b','c']) ?
Edit: sorry ... actually - read the code wrong again --- ... note to self - don't read code before coffee in the morning.....

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.