Solidity: "a =+ b" is not "a = a + b"

[rolandkofler]

In fact it just overrides the variable.

var a = 0;
a =+ 2;
a =+ 3; // result is 3

a = 0;
a += 2;
a += 3; // result is 5

I know that JS does the same, but other languages do not follow this unintuitive behavior and its a source of confusion and bugs.

Btw, currently its possible to write a +=+ 1; ... funny.

https://gist.github.com/anonymous/07732c159557334c8135e23e5373e7dd#file-untitled-L13au

[axic]

I would assume a =+ 3; is parsed as a = +3, i.e. the plus is the sign of the variable. There's no operator =+;

I think the question here is whether plus prefixes for numbers should be accepted or not.

[rolandkofler]

This would not solve the question because the same applies for minus: a = -1 is a necessity and a =- 1 gets you in trouble. Since spaces are just decoration and not semantically loaded I don't see a pretty solution.

[axic]

I am a bit confused why do you think -= equals to =- and += equals to =+?

[pirapira]

I think the next step (or the final goal) of this issue is unclear. I add "more info please" label.

[rolandkofler]

Maybe this attack supports the urgency a bit more:

https://www.reddit.com/r/ethereum/comments/5lzw0e/psa_hackergolds_hkg_token_has_a_bug_and_will_need/

@pirapira probably a static analysis warning would be a first remedy? I'd prefer that the language prohibits =+ at all

[chriseth]

Yes, we could add such an analysis step to the browser-solidity static analyser (should also be quite easy to do that for an external contributor).

[VoR0220]

@rolandkofler the problem with prohibiting that is that it actually does have a legitimate purpose as a unary operator. As for other languages not supporting it...Golang supports it...JS supports it...C++ supports it...Python supports it...I'm not aware of any languages that don't also have this functionality...the stakes are merely higher in a blockchain context and comes under much more scrutiny when faced with situations like the recent "attack". But I do agree...some warning or static analyser step should be added.

[VoR0220]

Ah finally found one that disallows it. Rust.

[rolandkofler]

So we have a historical track record of allowing a=+1 and spaced variaties. The options are

• static analyzer warning for =+, =-
• deprecating = += -= *= /= ...
• status quo

I think deprecating is the most elegant option because the gain is so little for the short form to have reason d'etre and it solves a easy mistake.

[pirapira]

@VoR0220 Also Ruby does not have it. Ruby does not have +=.

[VoR0220]

@rolandkofler I think there's the simple legitimate use case of converting a negative to a positive...and I think that alone is enough to keep the unary operator functioning as it does. I think if one is serious enough about their contracts, they should be employing proper unit testing to make sure that their contracts behave as they should (and that was clearly not employed in this recent "attack"). However, some kind of warning should more than suffice for ease of debugging enabling people to correct their mistake if they are serious about deployment. That's my two cents.

[rolandkofler]

@VoR0220

I think there's the simple legitimate use case of converting a negative to a positive

you mean b = -a; ? yes I agree. What I would deprecate is the += shortcut and its cousins -= *= \=...
If humans have a hard time to interprete a +=+ 1 correctly then this sintactic sugar is not justified.

[federicobond]

deprecating = += -= *= /= ...

I don't understand this option. Why not deprecate the unary plus, which is the useless construct here, instead of all the useful assignment operators?

The unary plus is meaningful in dynamically typed JavaScript to coerce values to numbers, and it is meaningful in C to promote values to integers. It's a no-op in Solidity.

[VoR0220]

@rolandkofler that's a good point, one could simply take the negative of a negative to get the positive value. I think deprecating the += and its cousins is an absolute non starter. It's a comfortable and often used shortcut.

with regards to @federicobond 's suggestion, this could be something of value to deprecate that would absolutely solve this problem.

@chriseth what do you think? Should we deprecate the unary +?

[rolandkofler]

It's a comfortable and often used shortcut.

Certainly it's a filosofical debate. What does Solidity value more comfort or clarity?
myValue += yourValue vs myValue = myValue + yourValue

[VoR0220]

that's a good question. I'm unsure of the answer. Personally I'm for the comfort and familiarity aspect.

[federicobond]

The primary driver for a smart contract language should be to make it very hard (or impossible) to write wrong code. All other considerations of clarity and comfort should be subordinated to this.

[VoR0220]

Agreed

[chriseth]

Solidity values comfort and clarity: somecomplicatedValue = somecomplioatedValue + x

[chriseth]

Unary addition will be deprecated and removed: https://github.com/ethereum/solidity/issues/1184 https://github.com/ethereum/solidity/issues/1760