On Mon, 04 May 2009 14:53:41 -0400, Unknown W. Brackets
<unkn...@simplemachines.org> wrote:
I've always though of arrays and associative arrays as structs (which
really is what they are.) Thinking that way, this behavior makes exact
sense - down to .length being unchangeable and associative arrays being
unchangeable.
I mean, you wouldn't want to make it work the way you suggest by making
arrays and associative arrays simply pointers to their current structs
(just like a class would be.) You could make such a class easily
yourself, anyway.
If you are right, I guess the right solution would be to make the ref
implicit when returning (or, I suppose, passing?) such arrays and
associative arrays. But that seems wrong to me too, and wouldn't come
free (speaking of efficiency) either.
-[Unknown]
The underlying struct of an AA is:
struct AA
{
AA_Implementation *impl;
}
or something like that ;) Look at the D runtime source.
But in any case, if you return an array slice, would you not want to be
able to update an element of the slice?
I think there is a difference between a value struct (where all internals
are non-reference types), and a reference struct (where at least one
element is a reference type). A reference struct should be able to pass
those references to other functions without having to be ref'd. It forces
non-transparent type wrapping if that isn't the case. I should be able to
replace a reference or pointer type with a wrapper struct where I can
modify the interface, and it should be transparent that I have done so
(except for the interface changes of course). I think this is one of the
goals D2 is working towards.
It makes sense that a value struct or the value types inside a reference
struct (i.e. the length of an array) should not be changeable as rvalues,
since you aren't going to use them later.
Both arrays (as the current implementation) and AA's are reference structs.
-Steve
