Scope Containers

[bitwise]

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:
>> On Sunday, 10 March 2019 at 12:06:10 UTC, Atila Neves wrote:
>>> [...]
>>
>> 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`.

Interesting. I'll have to look up some examples.

>> 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

Ok, but this container copies the entire collection in postblit:
https://github.com/atilaneves/automem/blob/2a97acba94d6fe0bf9ba07fec99e86e46aa0f2a1/source/automem/vector.d#L104

So if you try to treat it like a range, you'll take a performance 
hit every time you trigger the postblit, which seems likely.

Isn't it reasonable to assume a range should act like a reference 
to data, rather than a copy of it?