i++

[hakunin]

I often find myself in need of i++, for example:

i = 0
rows.each { |row|
  row_class = (i % 2 == 0) ? "even" : "odd"
  html += "..."
  i += 1
}

Writing i += 1 sucks. Also i++ seems to be more expressive because I don't mean to add one, I man to increment.

[headius]

I agree. I have never liked the lack of i++ in Ruby, and I don't buy that it's misleading to make it an alias for "i += 1".

Java itself makes no explicit guarantees about ++ atomicity, making it atomic for local variables (iinc bytecode) and non-atomic for fields or array elements. So for us, making ++ follow the same atomicity guarantees seems quite reasonable.

[baroquebobcat]

How hard would it be to do this, do we want it in 0.0.8?

[consiliens]

"Comment 3 by rogerpack2005, May 28, 2011
++ !"
http://code.google.com/p/mirah/issues/detail?id=19

[baroquebobcat]

++ does this currently:

$ mirah -e "i=1;i++"
expected terms before '++' (at line: 1, char: 5)

I think it's because it's not in the grammar yet. I think you change the grammar through this file ( https://github.com/mirah/mirah-parser/blob/master/src/mirahparser/impl/Mirah.mmeta ) in the mirah-parser project.

[felixvf]

I’d like to close this as "WONTFIX".

Ruby does not have "i++", Crystal does not have "i++" and

f(i++,a[i++],i++)[i++] = b[i++] + c[i++]

is not well defined.

In addition, unlike some languages close to machine code (C), there is no performance optimization to say "i++". Instead, "i++" will always have to translate to the bytecode of "i+=1".

In addition, there is no clear meaning of "++"-style postfix operators. Should i++ mean the same as i = i.+(1)? If so, should i-- mean the same as i = i.-(1)? If so, should i** mean the same as i = i.*(1)? If so, should i// mean the same as i = i./(1)? If so, should i&& mean the same as i = i.&(1)?

Apparently, it is not useful to extend this concept to operators beyond "++" or "--". But if the concept is not generic enough, is its ungenericness, its peculiarity, its oddity warranted by its usefulness? I doubt that. In C and C++, "++" works on integers and pointers. In Mirah, we do not have pointer arithmetic. And we do not need explicit incrementing as often as in C, as we have #each, #map and other ways of iterating.

So I’m up for closing this.

However, if there is a strong need, I’m open for patches which make postfix "++" and postfix "--" an operator, so users can define their own meaning of "++" by defining a macro int#++ if the really want to.

[baroquebobcat]

I agree. I've been reading some C recently and I'd say postfix ++ has some allowed usages that end up being really confusing. On May 12, 2017 7:05 PM, "Felix von Ferey" <notifications@github.com> wrote: I’d like to close this as "WONTFIX". Ruby does not have "i++", Crystal does not have "i++" and f(i++,a[i++],i++)[i++] = b[i++] + c[i++] is not well defined. In addition, unlike some languages close to machine code (C), there is no performance optimization to say "i++". Instead, "i++" will always have to translate to the bytecode of "i+=1". In addition, there is no clear meaning of "++"-style postfix operators. Should i++ mean the same as i = i.+(1)? If so, should i-- mean the same as i = i.-(1)? If so, should i** mean the same as i = i.*(1)? If so, should i// mean the same as i = i./(1)? If so, should i&& mean the same as i = i.&(1)? Apparently, it is not useful to extend this concept to operators beyond "++" or "--". But if the concept is not generic enough, is its ungenericness, its peculiarity, its oddity warranted by its usefulness? I doubt that. In C and C++, "++" works on integers and pointers. In Mirah, we do not have pointer arithmetic. And we do not need explicit incrementing as often as in C, as we have #each, #map and other ways of iterating. So I’m up for closing this. However, if there is a strong need, I’m open for patches which make postfix "++" and postfix "--" an operator, so users can define their own meaning of "++" by defining a macro int#++ if the really want to. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAc0he8uVlWVy6Hy_LOSqB6qRYE7_5Tks5r5QHEgaJpZM4NZ6nQ> .