Scope Containers

[Atila Neves]

On Sunday, 10 March 2019 at 15:12:03 UTC, bitwise wrote:
> On Sunday, 10 March 2019 at 12:06:10 UTC, Atila Neves wrote:
>>
>> I wrote this:
>>
>> https://github.com/atilaneves/automem/blob/master/source/automem/vector.d
>
> I'm confused by the use of scope. For example, what effect does 
> scope have here?
>
> this(this) scope { ... }

Like `const`, `scope` on a member function means that the `this` 
reference is `scope`.

> I don't see any ranges/iterators in that class either,

https://github.com/atilaneves/automem/blob/2a97acba94d6fe0bf9ba07fec99e86e46aa0f2a1/source/automem/vector.d#L134
https://github.com/atilaneves/automem/blob/2a97acba94d6fe0bf9ba07fec99e86e46aa0f2a1/source/automem/vector.d#L159
https://github.com/atilaneves/automem/blob/2a97acba94d6fe0bf9ba07fec99e86e46aa0f2a1/source/automem/vector.d#L145

static assert(isInputRange!(Vector!int));

> At present, it seems impossible to create a memory-safe 
> container that supports iterators or ranges in D, unless it's 
> entirely GC.
>
> The best attempt I've seen is std.Array, which uses a 
> ref-counted/pointer-to-pointer payload to make sure any ranges 
> that were given out can see the changes to the payload. Isn't 
> it specified that a struct should be moveable in D though? So 
> as soon as you memcpy an std.Array everything starts 
> exploding/double-deleting. Also, this seems like it would apply 
> to *any* library based ref-counted implementation. So it seems 
> like scope is the last hope for creating an @safe @nogc 
> container that can give out ranges/iterators. Even adding a 
> move-constructor to D seems like a no-go since it's expected 
> that structs can be memcpy'ed.
>
> Am I wrong about this?

I would think so, especially since I wrote Vector to be @safe 
with dip1000. Look at this unit test for not being able to escape 
the payload for example:

https://github.com/atilaneves/automem/blob/master/tests/ut/vector.d#L229