Documentation of D arrays

[Jarrett Billingsley]

"Sebastian Biallas" <groups.5.sepp at spamgourmet.com> wrote in message 
news:eo6ofq$1q2b$2 at digitaldaemon.com...
>
> But not (Array *) but (len, byte *), I guess?

Yeah, it's more like (in fact, _exactly_ like) passing around a two-element 
struct by value.  If you pass a struct by value into a function and modify 
its members, those changes won't be reflected in the calling function unless 
you use 'inout'.  The same thing applies for arrays since this is really 
what's going on behind the scenes.
>
> Hmm, I'm quite sure I can alter the ptr, too (Implicitly, when I append
> to the array and there is not enough room).

Yes, that's right.

> Well, the word "reference" is way to much overloaded. Here you don't
> pass the Array (you mentioned above) by reference but the content (the
> object ptr points to).

Yes, and this got me a few times too.  Though most of the time I don't need 
a function to modify an array that's passed into it, just one that's a class 
member, or maybe modify it and then return it.

> Is there something similar to the "const" keyword of C/C++ in D? It
> looks a little bit fishy to me, that you can write illegal code in D so
> easy.. In C/C++ you can return constant array in way, that the caller
> a) knows, it's constant
> b) errors are detected at compiler time.

No, and this issue has been beaten absolutely to death.  I really don't care 
what happens with this issue.  I've never actually run into any bugs that 
would be solved by having const, but your mileage may vary, I guess. 
PLEASE, I don't want to start another topic about this :)

> For some values of "work" :)

Hehe

> But without the COW part?

COW is not part of the language.  It's just a convention you can follow when 
writing array-processing functions.  These functions also typically return 
the array, so the function should be called as "s = foo(s)" instead of 
"foo(s)".  The "COW" behavior that you were talking about before -- how 
resizing/reallocating the array in the function had no effect in the 
caller -- was really just an effect of what I mentioned at the beginning of 
this post.  The local array "structure" members were changed in the array 
processing function when you resized the array, and those changes aren't 
reflected in the calling function.

> Hmm, that's not the answer I hoped I'd get :)
> It's nice to have a language without suprises, but I could only figure
> out that the above part by trying it.

At least it's a nice surprise :)