bug in assigning to dynamic array element

[Steven Schveighoffer via Digitalmars-d]

On 11/1/14 10:44 AM, Iain Buclaw via Digitalmars-d wrote:
> On 1 November 2014 14:19, ketmar via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Sat, 1 Nov 2014 13:56:49 +0000
>> Iain Buclaw via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>>
>>>> if such assigns will be forbidden for any arrays... this is even worse.
>>>> "what? your shiny language can't do what even the simpliest C compiler
>>>> can do? now try to convince me that D is not a toy."
>>> That - for sure - is where you're wrong. :-)
>> i was talking about C, not that abomination. but if D will compete with
>> C++ for the quirks... than C++ is a winner. ;-)
>>
>> besides, i clearly see 'list.ptr' there. i don't see 'dynArray.ptr' in
>> D code. if i was using '.ptr' directly and it changes by the way... ok,
>> it was my fault. but i never used '.ptr' in my sample!
>
> You can clearly see the 'list.length' though.  You can't possibly go
> off the assumption that if you grow the size of a dynamic array, it's
> area in memory won't be relocated.

I think his assumption is that an array reference should not *re-alias* 
into another array.

This is the problem with calling them dynamic arrays -- they are slices 
of dynamic arrays. And altering the length of a slice can make it point 
at an entirely new dynamic array, with the original array (and in fact 
the original slice) still intact.

If, for example, the array was an object, and it's *private* underlying 
storage moved, well then the opIndexAssign would use the new storage, 
and the array reference doesn't actually change. I don't think it's 
unreasonable to expect this, but that's based on an incorrect 
understanding of how D dynamic arrays work.

There is a reason we get at least 1 question a week on how D arrays work.

-Steve