The Demise of Dynamic Arrays?!

[Andrei Alexandrescu]

S wrote:
> On 2009-12-15 10:21:04 -0800, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> retard wrote:
>>> Tue, 15 Dec 2009 09:42:26 -0500, Steven Schveighoffer wrote:
>>>
>>>> On Tue, 15 Dec 2009 02:25:11 -0500, S <S at s.com> 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).
>>>> It's not going away.  The plan as I understand it(*) is to fix dynamic
>>>> array stomping problems, and make thread-local dynamic arrays append
>>>> efficiently without using the GC lock where possible.
>>>>
>>>> -Steve
>>>>
>>>> (*) I am not Walter Bright/Andrei Alexandrescu and so I do not have any
>>>> final word on what makes it into D2 or not, these are just speculations
>>>>  from communications I've been involved in.
>>>
>>> Most likely Walter won't even tell what kind of arrays D2 will have. 
>>> Anything can happen. The final word is the undocumented executable 
>>> you can download when the book hits stores.
>>
>> That's a bit of an oxymoron isn't it :o). The book _is_ the 
>> documentation, and the chapter dedicated to arrays has been public for 
>> a while.
>>
>> http://erdani.com/d/thermopylae.pdf
>>
>>
>> Andrei
> 
> Alright Andrei,
> 
> I respect your expertise.   I'm going to go read this chapter and then 
> give you a piece of my mind.

Thank you, but I think you are overrating my expertise. I can't claim I 
am a programming language designer.

> But I will say this -- I hope the solutoin is good :)  Pretty much all 
> the arrays in D are messed up, and have been that way for the last 10 
> years since they "sort of behave" like Python, and "sort of behave" like C.
> 
> This code is listed as nonfunctioning:
> 
> int[] a = [0, 10, 20, 30, 40, 50, 60, 70];
> auto b = a[4 .. $];
> a=a[0..4]; // At this point a and b are adjacent
> a ~= [0, 0, 0, 0];
> assert(b == [40, 50, 60, 70]); // passes; a got reallocated
> 
> But how is it ever supposed to work.   Does the GC look at more than 
> start block addresses?
> 

There was a long thread regarding this matter, entitled "LRU cache for 
~=". You may want to look it up. The thread title is due to me and has a 
mistake, it should have been "MRU" = most recently used. "LRU" is the 
negation of that, reflecting the eviction policy (least recently used 
entry is evicted).


Andrei