Scope Containers

[bitwise]

On Monday, 11 March 2019 at 20:02:05 UTC, Atila Neves wrote:
> On Monday, 11 March 2019 at 19:40:06 UTC, bitwise wrote:
>> On Monday, 11 March 2019 at 18:29:23 UTC, Atila Neves wrote:
>>> On Monday, 11 March 2019 at 17:00:35 UTC, bitwise wrote:
>>>> On Sunday, 10 March 2019 at 18:46:14 UTC, Atila Neves wrote:
>>>>> On Sunday, 10 March 2019 at 17:36:09 UTC, bitwise wrote:
>>>>>> On Sunday, 10 March 2019 at 16:10:10 UTC, Atila Neves 
>>>>>> wrote:
>>>>>>> On Sunday, 10 March 2019 at 15:12:03 UTC, bitwise wrote:
>>>>>>>> [...]
>>>>>>>
>>
>> <snip>
>
>> I see now that you can iterate by returning a scoped slice of 
>> the internal data store, but this could be unsafe too. If you 
>> called reserve on the container, the returned slice could end 
>> up dangling if a non-gc allocator was used, even if the 
>> returned slice was scoped.
>
> Unless there's a bug in my implementation or in dip1000, no, it 
> can't be unsafe.

So if I use opSlice() to retrieve a slice of the internal array, 
then call reserve on the vector causing it to deallocate, then 
try to access the slice I just retrieved, what would you call 
that?

>> I think that if opSlice returned a scoped range with a pointer 
>> back to the original container,
>
> It does.

https://github.com/atilaneves/automem/blob/e34b2b0c1510efd91064a9cbf83cbf43856c1a5c/source/automem/vector.d#L284

I mean a custom range object that contains a pointer back to the 
original container. This code returns a pointer directly to 
memory inside the container. It's not wrapped in a range object, 
and it doesn't have any pointer back to the vector, which it 
would need because the internal memory of the vector could be 
deallocated, but the actual vector object itself could not 
(relative to the scoped range). At most, the container could be 
moved from and considered empty by the range it returned.

>> As long as the range couldn't leave the stack-frame of the 
>> container, I think this would be totally safe.
>
> It can't; that's the whole point of dip1000. Again, that's why 
> this test passes:
>
> https://github.com/atilaneves/automem/blob/e34b2b0c1510efd91064a9cbf83cbf43856c1a5c/tests/ut/vector.d#L229

I was referring to my suggested implementation of a range, not 
the slice returned by automem/vector. automem/vector's opSlice() 
could potentially allow you to dereference an invalid pointer. I 
don't know if detecting that is within the scope of dip1000, but 
I would still consider it a hole in the implementation.