Order of evaluation of post-increment operator

2014-12-28 Thread Gary Willoughby via Digitalmars-d-learn
I was just taking a look at the following poll[1] about the order of evaluation when using the post-increment operator. The following D snippet shows an example. import std.stdio; void main(string[] args) { auto foo = [0, 0]; int i = 0;

Re: Order of evaluation of post-increment operator

2014-12-28 Thread Joakim via Digitalmars-d-learn
On Sunday, 28 December 2014 at 14:51:22 UTC, Gary Willoughby wrote: I was just taking a look at the following poll[1] about the order of evaluation when using the post-increment operator. The following D snippet shows an example. import std.stdio; void main(string[] args)

Re: Order of evaluation of post-increment operator

2014-12-28 Thread bearophile via Digitalmars-d-learn
Gary Willoughby: 2. Is there anywhere this order of evaluation is documented? Currently that code is undefined in D too, and the compiler doesn't even give a compilation error. But Walter has said many times that it will become defined in D (IMHO it must be). Bye, bearophile

Re: Order of evaluation of post-increment operator

2014-12-28 Thread via Digitalmars-d-learn
On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote: (IMHO it must be). Disallowing is an alternative to consider. Even defined behaviour can be unintuitive and error prone.

Re: Order of evaluation of post-increment operator

2014-12-28 Thread John Colvin via Digitalmars-d-learn
On Sunday, 28 December 2014 at 17:34:52 UTC, Marc Schütz wrote: On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote: (IMHO it must be). Disallowing is an alternative to consider. Even defined behaviour can be unintuitive and error prone. I guess there are cases where it's not

Re: Order of evaluation of post-increment operator

2014-12-28 Thread bearophile via Digitalmars-d-learn
Marc Schütz: On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote: (IMHO it must be). Disallowing is an alternative to consider. Even defined behaviour can be unintuitive and error prone. Right. Bye, bearophile

Re: Order of evaluation of post-increment operator

2014-12-28 Thread bearophile via Digitalmars-d-learn
John Colvin: I guess there are cases where it's not easily catchable: void foo(int* p0, int* p1) { (*p0)++ = (*p1)++; } what happens when p0 == p1? The undefined code can be found statically, the run-time values are irrelevant. Bye, bearophile

Re: Order of evaluation of post-increment operator

2014-12-28 Thread ketmar via Digitalmars-d-learn
On Sun, 28 Dec 2014 17:34:50 + via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Sunday, 28 December 2014 at 16:05:32 UTC, bearophile wrote: (IMHO it must be). Disallowing is an alternative to consider. Even defined behaviour can be unintuitive and error prone. yep,

Re: Order of evaluation of post-increment operator

2014-12-28 Thread aldanor via Digitalmars-d-learn
On Sunday, 28 December 2014 at 14:51:22 UTC, Gary Willoughby wrote: I was just taking a look at the following poll[1] about the order of evaluation when using the post-increment operator. The following D snippet shows an example. import std.stdio; void main(string[] args)

Re: Order of evaluation of post-increment operator

2014-12-28 Thread John Colvin via Digitalmars-d-learn
On Sunday, 28 December 2014 at 20:25:59 UTC, bearophile wrote: John Colvin: I guess there are cases where it's not easily catchable: void foo(int* p0, int* p1) { (*p0)++ = (*p1)++; } what happens when p0 == p1? The undefined code can be found statically, the run-time values are