On 02/09/2016 11:18 PM, Nick Treleaven wrote:
Hi,
I've been working on a proof of concept Reference Counted Slice
container, based on the one in DIP1000. That one now has opAssign marked
@system, see:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#owning-containers

So I decided to make an RCSlice with a @safe opAssign (and @safe
destroy, std.algorithm.move). opIndex is no longer a direct member,
instead indexing RCSlice causes the compiler to create a RCRef temporary
struct (via alias this), which does have opIndex:

https://github.com/ntrel/stuff/blob/master/typecons/rcref.d

The temporary struct is a private type, returned as an rvalue, so can't
itself be passed by ref, so it should avoid the paired ref argument case
mentioned in the above DIP1000 link.

RCRef increments *RCSlice.count on construction and decrements on
destruction, but first checks that *count is > 1. If this fails, an
AssertError is thrown. When -noboundschecks is passed, the code assumes
no safety checks should be made for RCSlice and compiles out all the
additional counting code.

Of course it would be great to have compile-time checks, so I'm looking
forward to a DIP for that. But in the meantime this appears to show D
can have @safe ref-counting now that DIP1000 is underway.

Thoughts?

I've got a much more advanced memory management solution[0].
I'm waiting on DIP1000 implementation before implementing it into it.

But over all I quite like this type approach.

[0] https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/memory/managed.d#L255

Reply via email to