I had a bug which came down to the following line today:

m_takeIndex = m_takeIndex++;

Actually this line does nothing. m_takeIndex remains at exactly the same value as before (tested with dmd 2.065).

Can someone please explain why? And would be suitable to warn about this, if it is correct behaviour?

Kind Regards
Benjamin Thaut

On Friday, 28 March 2014 at 16:54:49 UTC, Benjamin Thaut wrote:
> I had a bug which came down to the following line today:
>
> m_takeIndex = m_takeIndex++;
>
> Actually this line does nothing. m_takeIndex remains at exactly the same value as before (tested with dmd 2.065).
>
> Can someone please explain why?

IT does nothing because that's post-increment: EG "save the current value, increment, return the old value".

Then you assign back the old value, effectively putting you back where you started:

int i = 5;

i = i++; //i is 5
then
i = 5; //i was incremented to 6
then
i is 5 again;

> And would be suitable to warn about this, if it is correct behaviour?

The problem here though is that we are talking about a "logical" no side effect: It *does* something, you just can't observe it.

Imagine this:

//----
void fun(ref i, ref j)
{
    i = j++;
}
void main()
{
    int a = 5;
    fun(a, a); //do nothing?
}
//----

This is to contrast with "i + j;" which is an *actual* no op.

Am 28.03.2014 18:03, schrieb monarch_dodra:
> On Friday, 28 March 2014 at 16:54:49 UTC, Benjamin Thaut wrote:
>> I had a bug which came down to the following line today:
>>
>> m_takeIndex = m_takeIndex++;
>>
>> Actually this line does nothing. m_takeIndex remains at exactly the
>> same value as before (tested with dmd 2.065).
>>
>> Can someone please explain why?
>
> IT does nothing because that's post-increment: EG "save the current
> value, increment, return the old value".
>
> Then you assign back the old value, effectively putting you back where
> you started:
>
> int i = 5;
>
> i = i++; //i is 5
> then
> i = 5; //i was incremented to 6
> then
> i is 5 again;
>
>> And would be suitable to warn about this, if it is correct behaviour?
>
> The problem here though is that we are talking about a "logical" no side
> effect: It *does* something, you just can't observe it.
>
> Imagine this:
>
> //----
> void fun(ref i, ref j)
> {
>      i = j++;
> }
> void main()
> {
>      int a = 5;
>      fun(a, a); //do nothing?
> }
> //----
>
> This is to contrast with "i + j;" which is an *actual* no op.

Well when I mean warning, I really only mean the

var = var++

case without any indirections. Because I can't think of a case where you actually want this.

Kind Regards
Benjamin Thaut

On Friday, 28 March 2014 at 16:54:49 UTC, Benjamin Thaut wrote:
> I had a bug which came down to the following line today:
>
> m_takeIndex = m_takeIndex++;
>
> Actually this line does nothing. m_takeIndex remains at exactly the same value as before (tested with dmd 2.065).
>
> Can someone please explain why? And would be suitable to warn about this, if it is correct behaviour?
>
> Kind Regards
> Benjamin Thaut

This should be invalid.

m_takeIndex++;

actually increments the variable.

m_takeIndex = m_takeIndex++; should do exactly the same.

It is a bug. It might be correct in monarch's world but it is not logical. I think monarch is just trying to justify the way D does it, regardless if D is D is wrong or not.

I imagine what is going on is that D is creating a temp variable, assigning it to the local variable, then incrementing the temp variable(since++ increments "after" the assignment).

That, or D really is treating that as a nop, which is wrong too.

Test case shows it is probably the first:

	int j = 0, i = 0;
	i = j++;
	// i = 0, j = 1

hence D is wrong, Monarch is wrong, etc...

m_takeIndex = m_takeIndex++;

should, given the example above, evaluate to

m_takeIndex = m_takeIndex; (a nop)
m_takeIndex++; (variable incremented)


hence, D is not consistent with itself, which at the very least is a bug.

I ran this:

import std.stdio;

void main() {
    int i = 10;
    i = i++;
    writeln(i);
}

with DMD32 D Compiler v2.063.2 and got '10'.

And for nothing other than curiousity, this in both VS2012, and VS2013:

#include <iostream>

int main(int argc, char const *argv[])
{
    int i = 10;
    i = i++;
    std::cout << i << std::endl;
    return 0;
}

and got '11', both times.





On Friday, 28 March 2014 at 18:04:41 UTC, Frustrated wrote:
> On Friday, 28 March 2014 at 16:54:49 UTC, Benjamin Thaut wrote:
>> I had a bug which came down to the following line today:
>>
>> m_takeIndex = m_takeIndex++;
>>
>> Actually this line does nothing. m_takeIndex remains at exactly the same value as before (tested with dmd 2.065).
>>
>> Can someone please explain why? And would be suitable to warn about this, if it is correct behaviour?
>>
>> Kind Regards
>> Benjamin Thaut
>
> This should be invalid.
>
> m_takeIndex++;
>
> actually increments the variable.
>
> m_takeIndex = m_takeIndex++; should do exactly the same.
>
> It is a bug. It might be correct in monarch's world but it is not logical. I think monarch is just trying to justify the way D does it, regardless if D is D is wrong or not.
>
> I imagine what is going on is that D is creating a temp variable, assigning it to the local variable, then incrementing the temp variable(since++ increments "after" the assignment).
>
> That, or D really is treating that as a nop, which is wrong too.
>
> Test case shows it is probably the first:
>
> 	int j = 0, i = 0;
> 	i = j++;
> 	// i = 0, j = 1
>
> hence D is wrong, Monarch is wrong, etc...
>
> m_takeIndex = m_takeIndex++;
>
> should, given the example above, evaluate to
>
> m_takeIndex = m_takeIndex; (a nop)
> m_takeIndex++; (variable incremented)
>
>
> hence, D is not consistent with itself, which at the very least is a bug.

On Friday, 28 March 2014 at 18:04:41 UTC, Frustrated wrote:
> On Friday, 28 March 2014 at 16:54:49 UTC, Benjamin Thaut wrote:
>> I had a bug which came down to the following line today:
>>
>> m_takeIndex = m_takeIndex++;
>>
>> Actually this line does nothing. m_takeIndex remains at exactly the same value as before (tested with dmd 2.065).
>>
>> Can someone please explain why? And would be suitable to warn about this, if it is correct behaviour?
>>
>> Kind Regards
>> Benjamin Thaut
>
> This should be invalid.
>
> m_takeIndex++;
>
> actually increments the variable.
>
> m_takeIndex = m_takeIndex++; should do exactly the same.
>
> It is a bug. It might be correct in monarch's world but it is not logical. I think monarch is just trying to justify the way D does it, regardless if D is D is wrong or not.
>
> I imagine what is going on is that D is creating a temp variable, assigning it to the local variable, then incrementing the temp variable(since++ increments "after" the assignment).
>
> That, or D really is treating that as a nop, which is wrong too.
>
> Test case shows it is probably the first:
>
> 	int j = 0, i = 0;
> 	i = j++;
> 	// i = 0, j = 1
>
> hence D is wrong, Monarch is wrong, etc...
>
> m_takeIndex = m_takeIndex++;
>
> should, given the example above, evaluate to
>
> m_takeIndex = m_takeIndex; (a nop)
> m_takeIndex++; (variable incremented)
>
>
> hence, D is not consistent with itself, which at the very least is a bug.

Monarch is right, expression value of i++ is the old i value. Right side of = is evaluated first, so i is incremented and then = is evaluated so it gets it's old value back. This is consistent with the rest of the language, your proposal is a special case.

> It is a bug. It might be correct in monarch's world but it is not logical. I think monarch is just trying to justify the way D does it, regardless if D is D is wrong or not.

You mean how *every* C-derived language does it?

On Friday, 28 March 2014 at 18:29:27 UTC, QAston wrote:
> On Friday, 28 March 2014 at 18:04:41 UTC, Frustrated wrote:
>> On Friday, 28 March 2014 at 16:54:49 UTC, Benjamin Thaut wrote:
>>> I had a bug which came down to the following line today:
>>>
>>> m_takeIndex = m_takeIndex++;
>>>
>>> Actually this line does nothing. m_takeIndex remains at exactly the same value as before (tested with dmd 2.065).
>>>
>>> Can someone please explain why? And would be suitable to warn about this, if it is correct behaviour?
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> This should be invalid.
>>
>> m_takeIndex++;
>>
>> actually increments the variable.
>>
>> m_takeIndex = m_takeIndex++; should do exactly the same.
>>
>> It is a bug. It might be correct in monarch's world but it is not logical. I think monarch is just trying to justify the way D does it, regardless if D is D is wrong or not.
>>
>> I imagine what is going on is that D is creating a temp variable, assigning it to the local variable, then incrementing the temp variable(since++ increments "after" the assignment).
>>
>> That, or D really is treating that as a nop, which is wrong too.
>>
>> Test case shows it is probably the first:
>>
>> 	int j = 0, i = 0;
>> 	i = j++;
>> 	// i = 0, j = 1
>>
>> hence D is wrong, Monarch is wrong, etc...
>>
>> m_takeIndex = m_takeIndex++;
>>
>> should, given the example above, evaluate to
>>
>> m_takeIndex = m_takeIndex; (a nop)
>> m_takeIndex++; (variable incremented)
>>
>>
>> hence, D is not consistent with itself, which at the very least is a bug.
>
> Monarch is right, expression value of i++ is the old i value. Right side of = is evaluated first, so i is incremented and then = is evaluated so it gets it's old value back. This is consistent with the rest of the language, your proposal is a special case.

Nope. Simple wrong. You even state what is happening
contradictory to what actually happens.

i = i++;
vs
i++;

different results. They shouldn't be.

i = i++; could be

i = i;
i++;

or

i++;
i = i;

or

i++;

either way, all increment i, which actually never happens in D.
As was pointed out, VS does it properly... D does it wrong.
Accept it and stop trying to validate how D does it so you can
say D is correct.

Not only is it logically wrong, it is not consistent with
previous interpretations of other compilers/languages nor with
itself. It is wrong on all levels. Just because you believe in
unicorns doesn't prove that they exist. All the evidence says you
are wrong.


What you guys are failing to realize is that

j = i;
i = j++;

is not the same as

i = i;
i = i++;

D also does not make the distinction, hence the error.

i = j++; is logically equivalent to

i = j;
j++;

which means, i = is the previous value of j(before increment).
This should hold true when j is an alias for i.

i = i;
i++;

which means i should be incremented. It is not. Why? Did monarch
code the increment routines in D?

I just wish we could agree that unicorns don't exist.

On Friday, 28 March 2014 at 19:35:22 UTC, Frustrated wrote:
> which means, i = is the previous value of j(before increment).
> This should hold true when j is an alias for i.

In this case: i = i++;  Means:

"i" is incremented by one, but the value assigned in "i" is the
previous one. That's it.

For me there's nothing wrong here.

Matheus.

On Fri, 28 Mar 2014 19:35:20 +0000, Frustrated wrote:

> 
> either way, all increment i, which actually never happens in D. As was pointed out, VS does it properly... D does it wrong. Accept it and stop trying to validate how D does it so you can say D is correct.
> 
> Not only is it logically wrong, it is not consistent with previous interpretations of other compilers/languages nor with itself. It is wrong on all levels. Just because you believe in unicorns doesn't prove that they exist. All the evidence says you are wrong.
> 

Nope, Frustrated is the one who is dead wrong.

test.c:
-----------------------------
#include <stdio.h>

int main()
{
	int i = 0;
	i = i++;
	printf("%i\n", i);
	return 0;
}
-----------------------------

$ gcc test.c && ./a.out
0

$ clang test.c && ./a.out
test.c:7:7: warning: multiple unsequenced modifications to 'i' [-
Wunsequenced]
        i = i++;
          ~  ^
1 warning generated.
0


Both gcc and clang agree that in C, assigning a post-increment to itself results in the original value.  At least Clang warns, which is good, but D is consistent with C's behavior on this point.

Justin