Wrapping a dynamic array with something as simple as
class Darray(T)
{
    T [] data;
}

lets you do
Darray!(int) a = new Darray!(int);
Darray!(int) b = a;

Which works as expected, ie, resizing 'a' still gives leaves you with a.data == b.data.

OK, so there is a work around.  It is debatable if this is more or less ugly
than the pointer to array syntax. (int [] *a, then using *a[0])
Can somebody please explain the rational for the current system?  As I see
it, the current system has no pros, only cons.  Ie currently:
 - Assignment of dynamic arrays is ambiguous, int [] a = b may be either a
reference to "b", or if a gets resized then b may be a copy.
 - The behaviour is inconsistant with the rest of D, where classes are
always by reference, unless explicitly copied.

I would argue that the following should be true:
int [] a; // create a reference to a length 0 dynamic array;
int [] b; // as above
a = b; // point a to the same underlying array as b - ie, just as object
assignment sematics work
a.length = 100; // resize the array that a (and b) points to
b[0] = 50; // set element 0 of b to 50, a[0] == b[0]

So a and b reference the same underlying array.  This way the dynamic array
semantics are identical to the object reference semantics, and we remove
the ambiguity that the current system has.
You may argue that having to update all the references to the underlying
array may be expensive, however:
 1 - This already happens for object references if the GC moves the object,
and nobody complains
 2 - Updating the references is probably not overly significant compared to
resizing the array.

Thoughts?

Cheers
Brad

J Anderson wrote:

> Right-t-o then.  I guess even that could be inefficient because then you need to keep track of which arrays are which.  If you wrap the array in a class then you'd have no problems.

Brad Beveridge wrote:

>Wrapping a dynamic array with something as simple as class Darray(T)
>{
>    T [] data;
>}
>
>lets you do Darray!(int) a = new Darray!(int);
>Darray!(int) b = a;
>
>Which works as expected, ie, resizing 'a' still gives leaves you with a.data
>== b.data.
>  
>

Obviously you would make the data private and use operators and methods to deal with the array.

>OK, so there is a work around.  It is debatable if this is more or less ugly
>than the pointer to array syntax. (int [] *a, then using *a[0])
>Can somebody please explain the rational for the current system?  As I see
>it, the current system has no pros, only cons.  Ie currently:
> - Assignment of dynamic arrays is ambiguous, int [] a = b may be either a
>reference to "b", or if a gets resized then b may be a copy.
> - The behaviour is inconsistant with the rest of D, where classes are
>always by reference, unless explicitly copied.
>
>I would argue that the following should be true:
>int [] a; // create a reference to a length 0 dynamic array;
>int [] b; // as above
>a = b; // point a to the same underlying array as b - ie, just as object
>assignment sematics work
>a.length = 100; // resize the array that a (and b) points to
>b[0] = 50; // set element 0 of b to 50, a[0] == b[0]
>
>So a and b reference the same underlying array.  This way the dynamic array
>semantics are identical to the object reference semantics, and we remove
>the ambiguity that the current system has.
>You may argue that having to update all the references to the underlying
>array may be expensive, however:
> 1 - This already happens for object references if the GC moves the object,
>and nobody complains
> 2 - Updating the references is probably not overly significant compared to
>resizing the array.
>
>Thoughts?
>
>Cheers
>Brad
>  
>

If it was done the way you suggest, you need another level of indirection which requires more memory.


>J Anderson wrote:
>
>  
>
>>Right-t-o then.  I guess even that could be inefficient because then you
>>need to keep track of which arrays are which.  If you wrap the array in
>>a class then you'd have no problems.
>>    
>>
>
>  
>


-- 
-Anderson: http://badmama.com.au/~anderson/

In article <cdsvhu$hc9$1@digitaldaemon.com>, Brad Beveridge says...
>
>I'm not advocating copy on write, I agree that behaviour like that is
>perhaps too inefficient to be part of the language.
>All I am saying is that if I do
>int [] orig;
>int [] other;
>other = orig;
>orig.length = 20;
>
>Then other and orig will always point to the same array, no matter if the array needs to be moved in order to satisfy the realloc.

Now here's the part that I don't understand - why would you want to have two variable names (orig and other in the above example) /in the same scope/ to be references to the same thing. If they're in the same scope, why not just refer to it by the same name consistently throughout.

If they're in /different/ scope, then the keyword inout does just fine, doesn't it?

#    int [] orig;
#    f(orig);
#    //orig.length is now 20
#
#    void f(inout int[] other)
#    {
#        other.length = 20;
#    }

Arcane Jill, probably talking rubbish again.

Arcane Jill wrote:

>In article <cdsvhu$hc9$1@digitaldaemon.com>, Brad Beveridge says...
>  
>
>>I'm not advocating copy on write, I agree that behaviour like that is
>>perhaps too inefficient to be part of the language.
>>All I am saying is that if I do
>>int [] orig;
>>int [] other;
>>other = orig;
>>orig.length = 20;
>>
>>Then other and orig will always point to the same array, no matter if the
>>array needs to be moved in order to satisfy the realloc.
>>    
>>
>
>Now here's the part that I don't understand - why would you want to have two
>variable names (orig and other in the above example) /in the same scope/ to be
>references to the same thing. If they're in the same scope, why not just refer
>to it by the same name consistently throughout.
>
>If they're in /different/ scope, then the keyword inout does just fine, doesn't
>it?
>
>#    int [] orig;
>#    f(orig);
>#    //orig.length is now 20
>#
>#    void f(inout int[] other)
>#    {
>#        other.length = 20;
>#    }
>
>Arcane Jill, probably talking rubbish again.
>
>  
>
Your right and wrong. Your wrong that your talking rubbish again, the rest is right.  I agree aliasing is a bad thing.


-- 
-Anderson: http://badmama.com.au/~anderson/

In article <cdsrhf$ec6$1@digitaldaemon.com>, Brad Beveridge says...
>
>But it isn't actually copy on write behaviour, because you can slice into an
>array and use that slice as a window into the main array.
>So what it really is, is copy on resize.  The rest of the time it is by
>reference.
>I've got no problems with copy on write, the thing that really irks me about
>this is the inconsistancy of it all - sometimes slices and copies can be
>used as methods to manipulate the main array, sometimes they can't.  And
>the problem is that you can't nessecarily be sure what you are getting.

I don't know.  Perhaps it's my experience with iterators and the STL, but I find the rules pretty straightforward.


Sean