Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

++ -- operations bug #1352

Closed
MadRabbit opened this Issue · 10 comments

5 participants

@MadRabbit

Hi,

It seems there is a bit of an issue with the ++ and -- operations when there is a space between a variable and the operation

smth++  # works
smth ++ # doesn't

Probably both versions should be supported

Cheers

@TrevorBurnham
Collaborator

CoffeeScript is stricter about whitespace between operators and operands than JavaScript is; this is the price of implicit parentheses. How, for instance, would you interpret

a ++ b

? It could either be a syntax error, or a(++b). If the latter, then wouldn't it be a bit odd for a ++ to mean a++?

Similarly, a frequent complaint that f +a and f + a have different meanings. Again, it's just the price of implicit parentheses; they imply certain stylistic limitations.

@satyr
Collaborator

a ++; is clearly postcrement. Reading it as a(++) is kinda dumb.

How, for instance, would you interpret

a ++ b

?

The same rule as +/- can apply.

@MadRabbit

Hi Trevor,

Good point. afaik they don't have ++ in ruby for the same reason. But, maybe it could be handled at least in those cases where it's pretty much clear what's going on, kinda like that

method i++, something
method ++i # nothing

If it's not too much of a trouble

@MadRabbit MadRabbit closed this
@TrevorBurnham
Collaborator

@satyr When you say of a ++ b that

The same rule as +/- can apply

what do you mean? Are you saying that a ++ b should compile to a ++ b?

@satyr
Collaborator

what do you mean? Are you saying that a ++ b should compile to a ++ b?

The same rule we use to enable a +b => a(+b) (check if the operator is spaced from the following token).
a ++ b would be read as (a++) b and cause syntax error.

@michaelficarra
Collaborator

@satyr:

a+ b -> a + b
a +b -> a(+b)
a + b -> a + b
a++ b -> currently syntax error, should be (a++)(b)
a ++b -> a(++b)
a ++ b -> ? (currently a(++b))

That last one does not have an obvious compilation. Both (a++)(b) and a(++b) appear valid to me, though a(++b) would almost certainly be the most commonly desired compilation. a ++ b (javascript) would not be a good compilation.

@satyr
Collaborator

Both (a++)(b) and a(++b) appear valid to me

The former doesn't make sense as a++ clearly isn't callable.

@michaelficarra
Collaborator

a++ clearly isn't callable.

That's not necessarily true. It's valid ECMAScript that will almost always throw a runtime error.

If a JS parser will parse it, we should be allowed to output it. There's no reason we should be able to write (a++) b and not a++ b. So that leaves a ++ b as ambiguous.

@satyr
Collaborator

almost always

You mean, you know a case that a++ returns a callable object?

If a JS parser will parse it, we should be allowed to output it

Allowing expressions that will only cause runtime errors benefits nobody. Accepting things like f() = x is a bad part of JS. We should try to reject them.
In fact, our = don't allow f() to the left, and our list of tokens for implicit call (CALLABLE in lexer) don't include ++/--.

@michaelficarra
Collaborator

No, I only meant to say that it was possible. You've given a convincing argument, though, and I now agree that compiling to a(++b) would be a perfectly reasonable assumption to make.

@vendethiel vendethiel added the bug label
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.