Enhanced array appending

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> 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.

Fluctuations in the speed of an operation are commonplace and don't 
require explanation for the putative user. Caches exist in many places 
in today's computers, and I don't see how all of a sudden this one cache 
sticks like a sore thumb.

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

The problem with T[new] vs. T[] was that it was very difficult to 
explain succintly when and how each should be used. I had two tables in 
TDPL and they were for the most part identical - I had to highlight the 
subtle differences. It's a far cry from arrays vs. hashes.

> 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 also think PHP's was not a brilliant idea, but I also think there's no 
comparison. There could be a way of agreeing if you came with a solid 
argument. For example in the thread about dropping binding "this" to an 
rvalue I had to acquiesce in wake of good counterexamples. Also, in the 
thread on "typedef" there was a good level of consensus that the feature 
doesn't pull its weight.


Andrei