RangeExtra

[Robert Jacques]

On Thu, 23 Apr 2009 19:00:10 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Robert Jacques wrote:
>> On Thu, 23 Apr 2009 14:37:37 -0400, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> dsimcha wrote:
>>>> CapacityArray:  A range that covers a builtin array and gives it a  
>>>> capacity
>>>> field.  All operations that don't have to do with appending are  
>>>> forwarded to
>>>> the underlying array via alias this (modulo a few compiler bugs),  
>>>> meaning that
>>>> a CapacityArray has an identical compile time interface to a builtin  
>>>> array,
>>>> and is implicitly convertible to one.
>>>
>>> Upon more thinking, I think we'll have to bit the bullet and define  
>>> Array!T and Slice!T. Then dmd rewrites:
>>>
>>> [ a, b, c ] -> .Array!(typeof(a))(a, b, c)
>>> T[new] -> .Array!(T)
>>> new T[n] -> .Array!(T)(n)
>>> T[] -> .Slice!(T)
>>>
>>> It seems increasingly clear that slices alone can't quite cut the  
>>> mustard.
>>>
>>> So your CapacityArray will essentially be the basis of Array.
>>  No. The capacity field hack only works with the current free-list  
>> based mark-sweep GC. In every other type of GC, the capacity is dynamic  
>> and can not be cached in the array itself. Introducing a language  
>> feature that is specific to an implementation seems like a bad idea.
>
> 1. STL does the same thing so it's likely a more general issue than one  
> might think.

1) Malloc generally uses a free-list based allocation scheme, so no, its  
not more general.
2) The STL is a library, not a language feature.

> 2. This is not a language feature. Different implementations can take  
> different routes.

Creating seperate types for slices and arrays is a language feature.

P.S. I think having array builders in Phobos is a good idea, I just don't  
think that they warrant a language change.