The Demise of Dynamic Arrays?!

[Lars T. Kyllingstad]

S wrote:
> Excuse me, because I haven't been active in the D community the last 
> year due to school concerns.  However, I have been  fiddling with the 
> language and on this newsgroups since 2001.
> 
> As I understand it, dynamic arrays are going away  soon in D2.0 in favor 
> of an ArrayBuilder class.
> 
> I don't like it at all.  I want to stomp my feet and throw a temper 
> tantrum.   As far as I am concerned, T[] has always been an 
> array-builder.   Now, I'd appreciate some considering, and that you'll 
> excuse my poor phrasing when it comes to terminology (I am not a trained 
> computer scientist).
> 
> For the last 9 years there has been problems with dynamic arrays.   Now, 
> I intend to enumerate the problems I have encountered and propose some 
> solutions, but let me first describe the internals of the D Arrays as I 
> understand them:  (To simplify)
> 
> struct Array(T) {
>     T* ptr;
>     uint length;
> }
> 
> So, D basically wraps this with various syntatic sugar.   Now, there 
> have been a variety of probelsm with using this same type for dynamic 
> arrays:
> 
> 1)  It has failed as an array builder because it does not contain the 
> length of the memory it references AS WELL as the actually number of 
> elements stored.   Thus cannot do pre-allocation like vector<> in C++STL 
> without some GC magic.   This make it slow to append.
> 
> 1-Solution) So, add an additional real_length parameter to dynamic 
> arrays.....
> 
> 2) If you take a slice, it often doesn't behave as expected.   Implement 
> a new type T[..] that are specifically slices of other arrays.     This 
> will add another parameter that references the array the slice came 
> from.   Thus, appending to a slice can behave as an insertion into it's 
> parent and other syntatic niceties.
> 
> 2-Solution) I propose that this type Arr[..]  would be implicitely 
> castable to other array types, at the expense of a dup.
> 
> 3) If dynamic arrays are passed, they pass the aformentioned struct 
> "by-value."  This however results in the ptr NOT being shared by the 
> function and its caller.   So, if a receiving function tries to append 
> to them it is possible that the sender doesn't notice the array has been 
> moved by the memory manager.
> 
> 3-Solution)  So, since static arrays are now pass-by-value.   Make this 
> true for dynamic arrays also, and provide a warning of some sort.    
> This would give you the expected read-only sematics of passing values 
> instead of the C one where [] == *.  Instead the proper way to pass a 
> read-write dynamic array would be by reference (AKA a Handle  ... 
> Computer Scientists solved this problem along time ago:  
> http://en.wikipedia.org/wiki/Handle_%28computing%29 ).    Now, this 
> causes some overhead in terms fo double look-ups for classes which might 
> not need to change the pointer address -- maybe there is some way around 
> doing this also though?
> 
> 
> *********   Did I miss anything?   Maybe my solutions are incomplete?  
> Please comment and revise this.    I think it would be a shame to get 
> rid of the syntatic sugar of dynamic arrays in support of an 
> ArrayBuilder class/struct.
> 
> -S.

This page describes the current future plans for D2 and Phobos, and is 
actually pretty much up-to-date:

   http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel

The section "Probably no longer required" near the bottom contains some 
links to the array discussions.

-Lars