built-in array ptrEnd

[Ben Davis]

On 18/09/2012 21:10, Nick Sabalausky wrote:
> On Tue, 18 Sep 2012 15:43:37 +0200
> "monarch_dodra" <monarchdodra at gmail.com> wrote:
>
>> On Tuesday, 18 September 2012 at 12:06:15 UTC, Steven
>> Schveighoffer wrote:
>>>
>>> There is another reason to avoid this.
>>>
>>> Note that if I have two consecutive blocks of memory:
>>>
>>> 0...4
>>> and
>>> 4...8
>>>
>>> If we define an array that points to the first block as a
>>> pointer to 0 and a pointer to 4, then that array also
>>> effectively points at the second block (4...8).  The way the GC
>>> works, it will not release the second block as long as you have
>>> a pointer to the first, even though the second pointer is not
>>> technically pointing at the block.
>>>
>>> -Steve
>>
>> That's a good point. I also shows another danger of ptrEnd: Not
>> only is it not a reference to the current range, it could *also*
>> be a reference to an un-related range.

Does the above not also mean that the second array's 'ptr' prevents the 
first array from being garbage-collected?

In any case, maybe the heap leaves gaps (perhaps if it has to insert 
metadata), so this is a non-issue anyway?

> FWIW, a ptrLast would avoid that (ie, arr.ptrLast == &arr[$-1])

That would make the problem worse for zero-length arrays though. Don't 
forget the corner-cases :)