Enhanced array appending

[grauzone]

Steven Schveighoffer wrote:
>> Also, if you use GC.malloc directly, and the user tries to append to 
>> slices to it, your code may break. GC.malloc doesn't seem to pad the 
>> memory block with a length field.
> 
> Yes, this is a possible problem.  However, using GC.malloc directly and 
> then treating the result as a normal array is probably extremely rare.  
> At least it is not valid for safe D.  It probably should be explained as 
> a danger in GC.malloc, but I don't think this will adversely affect most 
> code.  There will be functions that should obviate the need for calling 
> GC.malloc to allocate an array (specifically, allocating uninitialized 
> data).

Maybe the whole "used size of memory block" (aka array length) thing 
should be built directly into the GC. Leaving GC.malloc this way would 
be a bit "shaky", and asks only for strange Heisenbugs.

>> I must say that I find your argumentation strange: didn't you say 
>> adding an additional field to the slice struct is too much overhead?
> 
> Overhead when passing around, not overhead for storage.  For example, 
> pushing 12 bytes onto the stack instead of 8 when calling a function 
> with a slice.  If you want safe appends, you need to store the 
> allocation length somewhere, there's no way around that.

But would it really matter outside of microbrenchmarks?

In cases where it _really_ matters, even slices with two members may be 
overhead, and programmers will split the slice into separate variables 
anyway as they optimize their code.

> developing stuff for Tango (Tango uses slices to get every ounce of 
> performance!), I'm convinced that as-fast-as-possible slice semantics 
> for passing around data is essential.

I've often seen Tango code mess with pointers directly, where slices 
could have been used for clearer, more readable code. I assume this was 
to get more performance.