The Demise of Dynamic Arrays?!

[S]

On 2009-12-15 00:15:17 -0800, "Lars T. Kyllingstad" 
<public at kyllingen.NOSPAMnet> said:

> 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

Me reading that section was the motivation for this post.   I don't see 
how any of the proposed solutions obviate the 3 main problems with 
arrays in D that I listed above?   Even the current one with 
thread-local-caching doesn't fix the misbehaviorof slices and arrays 
having psuedo-reference semantics.

-S.