On 28-3-2013 17:52, Jonas Maebe wrote:
+= does *not* prevent re-evaluating the left side. It is internally
translated to x:=x+y and then evaluated like normal. So if x
contains a function call with side effects, these side effects are still
triggered twice.
Is evaluated as x := x + y or as x
On 02 Apr 2013, at 11:11, Marc Weustink wrote:
On 28-3-2013 17:52, Jonas Maebe wrote:
+= does *not* prevent re-evaluating the left side. It is internally
translated to x:=x+y and then evaluated like normal. So if x
contains a function call with side effects, these side effects are
still
Hmm... Haskell? Or Nimrod? Or something else? What's the benefit? How will it
affect existing code? Last but not least, will you implement it?
--
View this message in context:
What's the benefit?
Same benefit as += to := ... +
You do not need to rewrite/compute the left side
How will it affect existing code?
Not at all, since old code using this, would not compile
Last but not least, will you implement it?
I can try
On 03/28/2013 04:20 PM, leledumbo wrote:
On 28 Mar 2013, at 17:50, Benito van der Zander wrote:
What's the benefit?
Same benefit as += to := ... +
You do not need to rewrite/compute the left side
+= does *not* prevent re-evaluating the left side. It is internally translated
to x:=x+y and then evaluated like normal. So if x
Same benefit as += to := ... +
You do not need to rewrite/compute the left side
Save typing only then, the same mistake the C style operator support have
done.
--
View this message in context:
As to the C-style += operator, I have one question, will it makes code
slightly faster? because if you use Inc() or Dec() there will be a function
call? or, the compiler will always try to inline Inc or Dec?
No, as been explained, it's internally translated to the equivalent non-C
style by the
