Scope Containers

[Atila Neves]

On Tuesday, 12 March 2019 at 21:06:17 UTC, bitwise wrote:
> On Tuesday, 12 March 2019 at 18:06:39 UTC, Petar Kirov 
> [ZombineDev] wrote:
>> On Monday, 11 March 2019 at 20:02:05 UTC, Atila Neves 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.
>>
>> I think that this is what @bitwise was talking about:
>> https://github.com/atilaneves/automem/issues/25
>
> I hadn't seen this, but yes, thanks.
>
>    Bit

After thinking about what @bitwise said, I was actually going to 
post back similar code.

The code in the github issue is problematic, but it's a far cry 
from how such errors are usually introduced in C++. Normally it's 
because another thread has a reference to the now dangling 
pointer, or calling a function with the slice means it gets 
escaped somewhere.

Another way would be to write this:


void oops(ref Vector!int vec, int[] slice);


Which is also convoluted. Neither case would pass code review.

Either way, thanks for pointing out the possible issue. I'm going 
to have to think long and hard about whether it's possible to fix 
it with the language we have now.