The demise of T[new]

[Walter Bright]

dsimcha wrote:
> The bugs in the current arrays are pretty nasty from a
> theoretical safety/purity point of view (esp. the one that's a hole in
> immutability), but are seldom run into in practice.

We'd like to get D to the point where guarantees can be offered. This 
really sets it apart from C++, which offers no guarantees, and safety 
only happens if the programmer carefully follows convention. We need to 
do something about those nasty corner cases.

Another issue is that D currently has two array types. Adding T[new] 
makes for 3 array types, and that starts to look like we couldn't figure 
out what we were doing.

And lastly, the reason to make a type a built-in one is in order to 
offer substantial advantages over a library one. If a library one can do 
  a good job, it is better to push it into the library. Making for a 
smaller core language makes it easier for people to get into D and feel 
comfortable with it.

I was getting hard pressed to find significant advantages for T[new] 
over a library type. In particular, I find few uses for resizeable 
arrays as opposed to slices which are everywhere. When resizeable arrays 
are needed, they are usually isolated in one function, and when the 
function returns the resizeable array no longer needs to be resized - it 
can be converted to a slice type.

Another interesting advantage to the library type for T[new] is it 
solves the problem of creating a safe immutable string. When the library 
T[new] is converted to an immutable string, the T[new] contents are 
removed - hence it won't be possible to create a mutable alias of an 
immutable string without a user-applied cast, which would not be allowed 
in safe mode.