bug in assigning to dynamic array element

[ketmar via Digitalmars-d]

On Sat, 1 Nov 2014 13:56:49 +0000
Iain Buclaw via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> So your only solution is to pre-allocate the ptr in the GC to prevent
> the .ptr from moving because it has been reallocated to another area
> to accommodate growth.
if this will be left as is, the only solution is to drop D. i already
know the language that is filled with UBs, and there are alot of code
written in that language already.

> > if such assigns will be left untouched, this will inevitably lead to
> > subtle bugs that are really hard to find.
> >
> Changing the behaviour may also create new bugs that are really hard to find.
please, what sane use can be for this misfeature? it has no sense, it's
not doing anything useful and it's plainly wrong.

> > if such assigns will be forbidden only for dynamic arrays, any sane
> > person will question that. "so i can do this for char[4] and can't do
> > this for char[]? and why do you have the same syntax for completely
> > different things then?"
> Some people are used to this idea. eg:
> 
> std::cout << "foo";
that's why i dropped C++. ;-)

> > 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141101/3f328f3d/attachment.sig>