The Demise of Dynamic Arrays?!

[Andrei Alexandrescu]

retard wrote:
> Tue, 15 Dec 2009 10:21:04 -0800, Andrei Alexandrescu wrote:
> 
>> 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
> 
> I guess the book would be The Documentation (tm) in a perfect world :) 
> However, if Walter doesn't say anything, that can as well mean that he 
> didn't like the contemporary compromise. Many things in D have changed so 
> many times that I cannot really tell when the decision is final.

Walter and I keep 100% in agreement regarding the contents of TDPL.

> Sometimes articulating even bad design decisions is better than staying 
> quiet. People widely acknowledge that some features in some language are 
> really bad, but since their authors have decided not to change those 
> anymore, the language users can rely on it, and some form of trust is 
> established.

There are only few design decisions that I can think of as patently bad. 
I think by and large D does considerably better than average in terms of 
warts it needs to live with. Many design awkwardnesses are simply 
because we didn't know how to do better. Some others are the best we 
could choose to satisfy an intricate web of compromises.


Andrei