Enhanced array appending

[Leandro Lucarella]

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

What about the cache? You have to explain to the users that there is
a possibility that their appends works blazing fast, except... well,
sometimes if you fill the cache they will suck. As gruzone said, find this
kind of weird behaviours will be very hard.

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

No, I said that I think arrays/slices as they are have better performance
(when you know exactly what you're doing and pre-allocate and do that kind
of tricks). Unless you are asking for some other kind of examples?

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

Yes.

> You think splitting the features into 2 different types with
> several overlapping features is easier to explain?

Yes. And I think they have overlapping features just like any other
2 containers, hashes and arrays have overlapping features, but they are
completely different beasts. Same goes for arrays and slices.

PHP have arrays and hashes combined in one type. You think that's a good
idea because arrays and hashes have overlapping features? I really don't,
and I do think arrays and slices are 2 completely different beasts that
needs to be separated in the language. I think that's the natural good
thing to do, not an optimization. I think D is broken by combining this
2 types into one. You don't think that (and it looks like Andrei and
Walter doesn't think that either) so there's no way we would agree on this
topic.

> I think that is why Andrei nixed the T[new] idea, because when he tried
> to explain it in TDPL, it was very unnatural.

Well, I don't know what Andrei tried to do, but I think Python does pretty
well with it, for example.

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

I can say exactly the same about you. That's why I said I don't argue
anymore about this (grrr! I don't know why I ended up doing it in this
thread). This is a matter of taste, you think array/slice combined are
easier to use and I don't. About performance, they only spot where
splitting arrays and slices would perform worse than the current
slice/arrays combined is in that you add an extra indirection for arrays
because of the reference semantics (but you need to pass around a word
less than with slices, so I don't know how the real impact of that would
be). Besides that, you can make both schemes as fast, I think. It all
depends on how you use those types.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y2K
<Aztech_> hmm, nothing major has happend, what an anticlimax
<CaPS> yeah
<CaPS> really sucks
<CaPS> I expected for Australia to sink into the sea or something
<CaPS> but nnoooooooo