[Issue 13670] bug in assigning to dynamic array element

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13670

--- Comment #5 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
(In reply to Ketmar Dark from comment #4)
> (In reply to Jonathan M Davis from comment #3)
> > (In reply to Ketmar Dark from comment #2)
> > > so i don't have to
> > > track if my variable is dynamic or static array manually.
> > 
> > In general, I'd be very worried about code that didn't care about whether it
> > was dealing with a dynamic array or a static array, because they're
> > fundamentally different types.
> so why so many efforts were spent to make dynamic arrays looks like static
> arrays? if they are "fundamentally different types", they shouldn't look the
> same. there must be another different operation for them with different
> syntax, different declaration syntax and so on. and compiler *must* at least
> warn me that it's so stupid that it can't make the simple code works as any
> sane person expected it to work.
> 
> and i still can't understand why i should manually track if my variable is
> of static array type or of dynamic array type. and i'm still sure that this
> code should never asserts, it's nonsense:

Static arrays are value types, whereas dynamic arrays are pseudo-reference
types. So yes, they're fundamentally different, and it's due to how their
memory is managed. There are some cases where it doesn't matter, but there are
others where it does, and some operations are outright illegal on a static
array that are perfectly legal on a dynamic one (e.g. assigning to length or
appending). Regardless, there are no static arrays in your code, so I don't see
why you're worried about telling the difference between a static array and a
dynamic array in the context of this issue.

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

It's failing because what you're doing on the right-hand side is mutating what
you're assigning to. It doesn't matter if arrays are involved or not. You're
going to run into trouble when you do that regardless of the type. Granted,
because it's hidden in the call to saveIt rather than being right there in the
expression, it's harder to catch, but that doesn't change the fact that it's
undefined behavior. There have been discussions about making it defined
behavior, in which case, it would probably be the case that you could rely on
info.list[idx] being evaluated before the call to saveIt, but even that could
be a funny, because what you're doing in the call to saveIt could cause
info.list to be reallocated, meaning that the assignment would be made to the
memory that the array referred to previously rather than after the call.

Mutating something at the same time that you're trying to assign to it just
begging for trouble, and even with the order of evalution defined, I think that
if the assignment is to a dynamic array, and you're doing anything in the
mutation which could cause the memory for the array to be reallocated, then
you're still going to have problems, because the memory backing the array could
be reallocated in the middle of the expression. You're trying to do something
that fundamentally is going to have problems.

> D smells. with all that "let's keep our legacy 'cause Random Reddit User
> will go insane despite the actual users are begging for fix that", "let's
> not bless dfix for another year", etc.
> 
> another hobbyst project that wastes years of my time. my bad, i have to
> recognize that hobbyst smell from the beginning and not hoping for the best.
> i'm glad that i was unsuccessfull pushing our development department towards
> D. they were right, there is no sense to learn another quirky language that
> has so little libraries when we already have quirky C++ with alot of
> libraries.

No offense, but you seem to blow up in discussions very quickly, which is not
at all conducive to having an intelligent conversation. If you're looking for
perfection in any language, you will be forever disappointed. Some of D's
problems can and will be fixed. Others are intrinsic to how things work, and
others might be nice to fix but won't be for various reasons (including things
like fixing the problem not being worth the code breakage that the fix would
cause).

If you want to point out things in D that you consider to be a problem and
think should be fixed, then great. Have at it. But don't expect that everyone
will agree with you or that things will change just because you want them to.
Some of the time, what you want to happen may very well happen (especially if a
bunch of other folks agree with you), but there are plenty of times where it
won't change. The same goes for ideas or complaints that any of the rest of us
have.

--