On Sat, 1 Nov 2014 12:01:04 +0000
Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 1 November 2014 11:56, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > On Sat, 01 Nov 2014 11:31:51 +0000
> > anonymous via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> >> I don't know how D defines this, and I couldn't find anything but a forum discussion [1] (which I didn't read all of). But unless it's explicitly stated that the right-hand side is evaluated first, there is no bug.
> > there is. compiler generates code that modifies random memory addresses. this is absolutely unacceptable. and this is just illogical if we want dynamic arrays to look and work like "normal" arrays. besides, it's easily fixable without any changes in evaluation order.
> 
> I'm not *entire* sure on that. :)
> 
> If the evaluation of LHS[IDX] has a side effect, you've broken LTR.
> 
> Think:
> Left => Index => Right
> 
> vs
> 
> Index => Right => Left
so forbid that. this kind of bugs are VERY hard to find, especially when dynamic arrays looks like ordinary static arrays in the source. compiler should emit error on the "assign code" with possible side effects for dynamic arrays, or this hole will pop again and again. a simple change in the unrelated part of code and... KABOOM! everything goes wrong.

On Sat, 1 Nov 2014 12:01:04 +0000
Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 1 November 2014 11:56, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > On Sat, 01 Nov 2014 11:31:51 +0000
> > anonymous via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> >> I don't know how D defines this, and I couldn't find anything but a forum discussion [1] (which I didn't read all of). But unless it's explicitly stated that the right-hand side is evaluated first, there is no bug.
> > there is. compiler generates code that modifies random memory addresses. this is absolutely unacceptable. and this is just illogical if we want dynamic arrays to look and work like "normal" arrays. besides, it's easily fixable without any changes in evaluation order.
> 
> I'm not *entire* sure on that. :)
> 
> If the evaluation of LHS[IDX] has a side effect, you've broken LTR.
> 
> Think:
> Left => Index => Right
> 
> vs
> 
> Index => Right => Left
p.s. besides, the following code LOOKS wrong:

  info.list[idx] = saveIt(info, count-1);
  assert(info.list[idx] != 0);

aren't it a nonsence if we know for sure that saveIt() will never
return zero? if the code *LOOKS* wrong, it is wrong. that assert()
should never fire by any logical means.

On 11/1/14 8:04 AM, ketmar via Digitalmars-d wrote:
> On Sat, 01 Nov 2014 11:55:53 +0000
> anonymous via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> On Saturday, 1 November 2014 at 11:50:34 UTC, ketmar via
>> Digitalmars-d wrote:
>>> this *IS* a bug. either compiler should error on this, or it
>>> shouldn't
>>> modify random memory. imagine the situation when old array
>>> contents not
>>> only collected by GC, but that memory was allocated to something
>>> completely different.
>>
>> The old array is still alive and kicking. The left-hand side
>> still references it. It wasn't collected. You're not writing to
>> random memory.
> so it's not only writes to the stale copy, but protects that copy from
> GC. what a great thing! and all this without even a small warning from
> compiler. i can expect such behavior from c or c++ with all their UB,
> but not from D. this is not only ugly, this is plainly wrong.
>

No, it's not. It's exactly as you requested when you wrote that code :)

Note, you can fix this by overloading opAssign in Info, and it should work as you expect. This will force a delay in the evaluation of which array is used until *after* the RHS is done.

-Steve