Old problem with performance

[Yigal Chripun]

Denis Koroskin wrote:
> On Fri, 13 Feb 2009 17:24:54 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Rainer Deyke wrote:
>>> Andrei Alexandrescu wrote:
>>>> C++ ctors won't do the right thing if you use pointers, which is the
>>>> moral equivalent of using T[] inside MathematicalVector. If you
>>>> refer to
>>>> std::vector instead, then that's a carefully-defined type that does
>>>> have
>>>> the right copy constructor defined.
>>> So where's the D equivalent of std::vector? Phobos has nothing.
>>
>> It will.
>>
>>> I was under the impression that native arrays were intended to be used
>>> directly in D, something I rarely do in C++. Certainly neither of the
>>> standard libraries has any hesitation about passing unadorned dynamic
>>> arrays around.
>>
>> Phobos2 plans to consistently consider T[] a range, not a full-fledged
>> array. A range corresponds to a pair of iterators in STL.
>>
>>
>> Andrei
>
> Will T[] get front, back, empty properties, and popFront(), popBack()
> methods?
> Perhaps, its the time T[] internal structure is changed!
> For example, ptr+size replaced by two pointers, some additional fields
> added etc..

once upon a time there was a huge discussion about template syntax.
one of the suggestions was:
A!(T) => A[t]

with such syntax we could use:
Array[T] - this would be an array with the added capacity field
Map[Key, Value] - instead of the current AA's
Set[T] - example of user defined template
...
Array[int] arr1; // dyn. array
Array[int, 3] arr2; static array with size 3

or maybe even better:
if n is constant => static array, otherwise dyn. with pre-set capacity
Array[int] arr3(n);

auto r = arr1[]; // range/slice of arr1

IMHO, it's not a good idea to have container types in the language. they 
should be provided by the stdlib and the language needs to provide only 
the syntax to make such types behave like builtins. D already provides 
operator overloads for that.