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@puremagic.com> wrote:
>> On Sat, 1 Nov 2014 13:56:49 +0000
>> Iain Buclaw via Digitalmars-d <digitalmars-d@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

On Monday, 3 November 2014 at 00:16:48 UTC, ketmar via Digitalmars-d wrote:
> error-prone code. no, this is not "another task for lint". not
> rejecting such code is "safe" in the terms of "program will not
> segfault", but it's obviously not safe in terms of "correct code".

Yes, this is a common complaint. Without solid semantic analysis it would probably be better to only have dynamic vectors as a library type with fat slices that are locked to the underlying array. That's what everybody expects from a dynamic array type anyway. …it is a reaaallyyy good idea to support what most people's assumptions about dynamic arrays…

D would gain more from relaxing "memory safe" language constructs and focus more on supporting programming constructs by semantic analysis. This is an area where the C++ crowd will be gridlocked to their backwards compatible mindset. But they are getting increasingly more powerful sanitizers…

On Mon, 03 Nov 2014 16:39:43 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Monday, 3 November 2014 at 00:16:48 UTC, ketmar via Digitalmars-d wrote:
> > error-prone code. no, this is not "another task for lint". not rejecting such code is "safe" in the terms of "program will not segfault", but it's obviously not safe in terms of "correct code".
> 
> Yes, this is a common complaint. Without solid semantic analysis it would probably be better to only have dynamic vectors as a library type with fat slices that are locked to the underlying array. That's what everybody expects from a dynamic array type anyway. …it is a reaaallyyy good idea to support what most people's assumptions about dynamic arrays…
> 
> D would gain more from relaxing "memory safe" language constructs and focus more on supporting programming constructs by semantic analysis. This is an area where the C++ crowd will be gridlocked to their backwards compatible mindset. But they are getting increasingly more powerful sanitizers…
good semantic analysis as a big task, i think we all understand it. as moving dynamic arrays out of core language is the thing that surely won't be approved, the only sane way to safely fix this issue without starting discussion about when .ptr must be loaded is just reject impure assigns to dynamic array elements. sure this will reject some cases where impure assigns are ok, but better be safe that sorry, isn't it? ah, it isn't for D.

sure, this decision will break some code. that's why it will never be approved, despite all hype about "safety".

at least leaving this feature "as is" should help C++ programmers to adopt D. they used to languages that has nothing common with sanity. ;-)

On Mon, 03 Nov 2014 09:50:26 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> There is a reason we get at least 1 question a week on how D arrays work.
and this is a clear sign that something is *very* wrong with them. i fully understand the mechanics behind dynamic arrays, slicing and so on. what i *can't* understand here is why compiler allowing me to shoot my foot even without a warning.

compiler *knows* that this is dynamic array. it *knows* that assign is impure (as saveIt() obviously not "pure" and it can't be). yet it silently allows me do that. it's *very* error-prone code. it's easy for compiler to reject such code (or at least warn me). but it choses to carefully hide the possible bug.

i'm nat talking about "it must work as i expect!" here. what i'm talking about is that D compiler allows potentialy unsafe and error-prone code. it's ok for pointers, i'm walking in dangerous area with pointers, but it's not ok when i using *built-in* *type*! it's like "ahahaha, let's see how smart you are! i will not warn you about problematic code (despite i can do that without big problems) and we'll see how fast you'll find that gotcha!"

it's very funny to read discussions about safety and environment variables here. they were boring before, but now i realised the sarcasm, and they becomes very amusing.

On Tuesday, 4 November 2014 at 01:52:00 UTC, ketmar via Digitalmars-d wrote:
> sure, this decision will break some code. that's why it will never be
> approved, despite all hype about "safety".
>
> at least leaving this feature "as is" should help C++ programmers to
> adopt D. they used to languages that has nothing common with
> sanity. ;-)

Yes…

http://en.wikipedia.org/wiki/Sequence_point
http://dlang.org/expression

D needs a major overhaul:

1. assigns should not be expressions, but statements

2. assign should be a sequence point, not UB.

3. re-allocation should always be explicit in non-library types.

Solves all issues.