Enhanced array appending

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> Leandro Lucarella Wrote:
> 
>> This is making the half-value, half-reference semantics of arrays
>> even worse, since now the capacity is "passed by reference" (at the
>> end of the array data) but the length and ptr as values.
> 
> This is absolutely false.  It does not make anything worse.  It may
> not make it as good as you want, but it definitely is better than the
> current situation.  The current situation is that the capacity is
> "invented" by the runtime to be exactly what you need if the slice is
> at the beginning of a block, or 0 if it's not.  Such a scheme is
> totally unsafe.  The proposed patch leaves all aspects of arrays and
> slices alone *except* for this one thing.
> 
>> I don't comment much about the patch (and the design) because I
>> already did so in the several threads about it. I think is a very
>> bad idea, I think dynamic arrays should be a proper reference type
>> (with ptr, length and capacity) and slices should be a value type
>> without appending (only with ptr and length).
> 
> I don't agree.  I like that slices and arrays are the same type, it
> allows for much cleaner code, and much less function duplication.  I
> see the "append extends into a block" as an optimization, one that
> currently is invalid, and with the patch is valid.  Disallowing
> appending to slices means you must generate arrays whenever you want
> to do appending (which copies the entire slice), incurring a higher
> cost for little gain.  I'd actually say no gain.  Do you have an
> example where such a scheme is better than arrays with my patch?
> 
> Note that nobody is stopping you from making such array types, you
> are free to add them.

At the risk of restarting the debate around T[new], let me note that 
Steve's intuition corroborates with our experience when we tried to 
define T[new].

Andrei