The demise of T[new]

[Denis Koroskin]

On Mon, 19 Oct 2009 01:05:39 +0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> The purpose of T[new] was to solve the problems T[] had with passing T[]  
> to a function and then the function resizes the T[]. What happens with  
> the original?
>
> The solution we came up with was to create a third array type, T[new],  
> which was a reference type.
>
> Andrei had the idea that T[new] could be dispensed with by making a  
> "builder" library type to handle creating arrays by doing things like  
> appending, and then delivering a finished T[] type. This is similar to  
> what std.outbuffer and std.array.Appender do, they just need a bit of  
> refining.
>
> The .length property of T[] would then become an rvalue only, not an  
> lvalue, and ~= would no longer be allowed for T[].
>
> We both feel that this would simplify D, make it more flexible, and  
> remove some awkward corner cases like the inability to say a.length++.
>
> What do you think?

Well, I personally don't feel much of a need for T[new], and I agree T[]  
needs to be "fixed" the way you describe (i.e. make a shrink-only range  
out of it).
But I believe a change like this coupled with a demise of T[new] would be  
way too restricting. Given a

T[] array;

What type would result of these operations be?

1) auto x = array.dup;
2) auto y = array ~ array;

T[] is a view into someone else's container. But when you create a new  
array (by dup'ing or concatenating), you get a fresh copy. It points to a  
beginning of data sequence, and there is nothing wrong to expand it.

I believe it should be T[new]. A reference type, yes, a type that would  
allow appending and would render Appender unnecessary.