Enhanced array appending

[Leandro Lucarella]

Steven Schveighoffer, el 24 de diciembre a las 10:15 me escribiste:
> 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.

I meant from the language semantics POV (you have more rules to remember
about arrays), I agree it makes things better from a practical POV.

> > 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.

I said this several times but here it comes again: We agree that the
current scheme is better in terms of performance than having a proper
reference type dynamic array and a separated slice value type.

The thing is, I think optimization is nice as long as it doesn't leak the
abstractions to the user. The current scheme is clearly this scenario, to
make an optimization (one that problably a lot of people wouldn't need),
you are making things harder for the user and creating a monster half
array, half slice that is harder to understand than 2 smaller and simpler
types.

You think this performance gain is more important than the added
complexity, I think the other way. You think D should be *by default* as
fast as possible, even when making the programmers life a little harder,
and let the user create or use library types for easy use and I think it
should be the exact opposite, make *default* things easier and not as
fast, and let the user create/user library types if they need top
performance/optimizations.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
MATAN AL PERRO: DICEN QUE ESTABA POSEIDO POR EL DEMONIO...
	-- Crónica TV