The demise of T[new]

[Denis Koroskin]

On Mon, 19 Oct 2009 01:55:28 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Denis Koroskin wrote:
>> 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.
>
> That was the exact plan. I even have half a chapter written about it  
> with nice figures and all, that I can make available. The problem was,  
> it sucked. Returning a distinct type from .dup and ~ makes slices not  
> closed over these operations, a source of complication, confusion, and  
> bloating.
>
> Andrei

What's problem with implicit cast of T[new] to T[]?

T[new] container = [1, 2, 3].dup;
T[] range1 = container; // implicit container[] call via alias this
T[] range2 = [1, 2, 3].dup; // same here

An other option would be to declare

// duplicates a range
T[] rdup(T[] range)
{
     return range.dup[];
}

but it's less likely to happen.