== Quote from downs (default_357-l...@yahoo.de)'s article
> Walter Bright 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?
> I think ArrayBuilder can work almost entirely transparently provided the
following conditions are met:
> 1) when trying to cat to an array, the first array automatically promotes to
ArrayBuilder
> 2) Setting .length is, depending on new length, either a slice or a cat
operation with the length difference.
> 2) ArrayBuilders implicitly cast to string.
> This should allow a syntax that is almost entirely identical to the one used
> in
D1, aside from typeof("a"~"b").stringof :)
> Is this feasible in D2?
Once you throw in all the implicit conversions to ArrayBuilder and having the
core
language know about ArrayBuilder, aren't you, for all practical purposes,
implementing T[new] but calling it ArrayBuilder?
