Denis Koroskin wrote:
On Mon, 19 Oct 2009 01:05:39 +0400, Walter Bright
<newshou...@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
