Enhanced array appending

[Steven Schveighoffer]

Leandro Lucarella Wrote:

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

In fact, semantics are simpler.  You can completely eliminate the explanation about stomping in the spec.

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

No example?

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

Really?  You think splitting the features into 2 different types with several overlapping features is easier to explain?  I think that is why Andrei nixed the T[new] idea, because when he tried to explain it in TDPL, it was very unnatural.

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

I think the whole basis of your argument is invalid -- the current array/slice combination type is easier to use and explain *and* performs better.

-Steve