RFC on range design for D2

[Sergey Gromov]

bearophile <bearophileHUGS at lycos.com> wrote:
> Sean Kelly:
> > I'd think that adding a capacity field should actually speed up append 
> > operations, since the GC wouldn't have to be queried to determine this 
> > info.
> 
> Yes, but I meant slower than just adding the capacity field without adding such extra bit flag to tell apart slices from arrays.
> 
> 
> > And as in another thread, the capacity of all slices should 
> > either be zero or the size of the slice, thus forcing a realloc for any 
> > append op.
> 
> Oh, right, no need to a separate bit for tagging then, is the value capacity=0 that's the tag.
> Do D designers like this (small) change in the language? :-)

It just doesn't work.  Arrays are structs passed by value.  If you pass 
a capacity-array into a function, function appends, then you append to 
your old copy, and you overwrite what the function appended.  If you 
force slice-on-copy semantics, then arrays become elusive, tending to 
implicitly turn to slices whenever you toss them around and then 
reallocate on append.

When I was reading D specs on slicing and appending for the first time 
I've got a strong feeling of hackery.  Slice is a view of another slice 
but you cannot count on that.  Slice can be appended to but you can 
erase parts of other slices in the process.  I've had my share of 
guessing when I was writing a sort of refactoring tool, when I checked 
carefully whether a slice would survive and dupped much more than I wish 
I had.

I'd personally love to have something as simple and natural to use as 
current built-in arrays but with better defined semantics.  I don't like 
Andrei's Array!() thingy but it seems better than anything proposed 
before.