RFC on range design for D2

[Oskar Linde]

Sean Kelly wrote:
> bearophile wrote:
>> Oskar Linde (and Andrei Alexandrescu):
>>> So by removing ~= from T[], T[] becomes a pure slice type.
>>
>> Appending to the built-in dynamic arrays is a fundamental operation (I 
>> use it hundred of times in my code) so if the purpose is just to avoid 
>> problems when extending slices, a different solution can be invented.

I agree that it is a fundamental operation, and my code contains 
hundreds of uses too. But the number of uses are actually fewer than I 
thought. One project of mine has only 157 ~= out of a total of 18000 
lines of code, and the cases are by their nature quite easily 
identified. Arbitrary code doesn't usually append to arbitrary slices.

>> For example adding the third (capacity) field to the dyn array struct, 
>> the last bit of the capacity field can be used to tell apart slices 
>> from true whole arrays. So at runtime the code knows how to 
>> extend/append the array/slice correctly. This slows down the appending 
>> itself a little, but it's better than having to use an ugly 
>> ArrayBuilder everywhere.
> 
> 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.  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.
> 
> 
> Sean

capacity = the size of of the slice won't work, since then you could 
transform a slice into a resizable array by mistake:

s = a[5..7];
// s.capacity = 2
t = s;
s.length = s.length - 1;
s ~= x;

so that basically means that capacity has to be = 0 for slices, and != 0 
for resizable arrays.

Without considering whether arrays would gain from having the capacity 
readily accessible, the advantage from this would be to have a run-time 
way to separate the slice from the array at the cost of 50 % increased 
storage. But even though this information would only be accessible at 
run-time, it is fully deducible at compile time. So you lose all compile 
time gains from separating the two concepts.

-- 
Oskar