Inability to dup/~ for const arrays of class objects

[Maxim Fomin]

On Thursday, 30 May 2013 at 07:57:41 UTC, Ali Çehreli wrote:
> On 05/30/2013 12:11 AM, Maxim Fomin wrote:
> > As a general programming notion - yes, in D (array spec page):
> > "Dynamic arrays consist of a length and a pointer to the
> array data."
>
> Then the spec is wrong because that is the definition of a 
> slice. The reason is, there is no dynamic array is sight below 
> but a static array and a slice:
>
>     int[10] arr;
>     int[] slice = arr;
>     assert(slice.ptr == &arr[0]);  // (yes, same as arr.ptr)

No, spec is right and article is wrong. It uses incorrect 
definition and calls correct definitions as incorrect. Is exactly 
what is writing an article calling dynamic array to be not a 
dynamic array but a banana and latter calling original definition 
incorrect because according to the article it is a banana.

> Even though 'slice' above "consists of a length a pointer to 
> the array data" despite the language of the spec, that is not a 
> dynamic array:
>
>     slice[0] = 42;
>
> The static array's element is changed, not some dynamic array's.

This does not mean that the object is not a dynamic array (false 
logic consequence).

> The correct description is that the 'slice' variable above is a 
> slice, having the ability to refer to elements of a dynamic 
> array and a static array.

static assert(typeof(slice) == typeof(int[])); // int[] type is 
dynamic array

this checks that object 'slice' is of type dynamic array. Note, 
that notion of slice is not embebed into compiler at all (you 
cannot test whether some object is of type 'slice' or not).

> (I know I am repeating the article at this point but it happens 
> to be the fact.) If there is no dynamic array to speak of 
> above, what is a dynamic array then? The answer is, dynamic 
> array is an entity that is owned and managed by the D runtime.

This is recalling incorrect definitions from article. You are 
simply assuming that dynamic array is runtime memory and 
everything which does not refer to runtime memory is not a 
dynamic array. This is wrong because dynamic array is not defined 
to be runtime memory and not promised to be in 100% cases. 
Consider example with typesafe variardic functions when dynamic 
array is constructed on caller side from stack memory. It is of 
type dynamic array yet it is not from runtime memory. By the way, 
this is good example of how incorrect definition confuses people 
and make them to write buggy code. I remember at least two bugs 
in bugzilla when people were complaining that 'dynamic array from 
typesafe variardic function seems not to refer to runtime memory'.

> For the above code to finally involve a dynamic array, we can 
> add an element to 'slice':
>
>     slice ~= 7;
>     assert(slice.ptr != &arr[0]);
>
> Now there is a dynamic array but it is not our 'slice' that is 
> the dynamic array. Here is the proof:
>
>     slice = arr[5 .. $];
>     assert(slice.ptr == &arr[5]);
>
> Has 'slice' been a dynamic array until that last assignment and 
> suddenly become a slice again? No, D does not involve type 
> changes like that. It has always been a slice, which is not the 
> same thing as a dynamic array.

One of the funny consequences of using incorrect definition is 
that is forces to call an entity as not a dynamic array and after 
some manipulations the same entity to call a dynamic array. This 
is obviously wrong because it is the same object.

> > This actually kills two misinterpretations encouraged by
> array article
> > that a) dynamic array is some kind of runtime memory
>
> I still think so.
>
> > b) that T[] data is not a dynamic array, it is a slice.
>
> I still think so.
>
> The spec must be outdated then; the array semantics have been 
> finalized relatively recently (in 2009? or 2010?).
>
> Ali

Actually the article should be updated in accordance with the 
spec.