@safe Allocators

[pbackus]

I wrote a long article about designing a @safe allocator interface in a Github Gist, here:

https://gist.github.com/pbackus/29c520bc4e1f4aa075c9171db791d234

I have a work-in-progress proof-of-concept library based on this design (with some small changes) at https://github.com/pbackus/allocator-demo.

This design depends heavily on two -preview features:

• -preview=systemVariables
• -preview=dip1000

If we choose to adopt a design like the one I've suggested, it will be necessary to stabilize those two language features before allocators can be included in Phobos.

[ichordev]

Uniqueness: there must not be any other references to the block.
Liveness: the block must not have been deallocated already.

Some of these concepts really deserve to be language features more than anything. There's just too much overhead in the current implementation of Block. I really liked the idea behind @live, I think it should be expanded upon for something just like this.

If a function parameter a Block is passed to is non-scope (or maybe marked with some attribute), the Block should be considered 'consumed', and is effectively barred from being re-used on the caller-side. This would be how the free function would work.

[pbackus]

The deallocate function actually does work the way you describe in my proof-of-concept implementation (i.e., I agree that's the correct approach). There's no need to do anything special with the function parameter—a normal by-value parameter is all that's needed. Because D doesn't have built-in move semantics, you have to write deallocate(move(block)) to call it.

Move semantics and a unique(T) qualifier are the two language features that would help the most with @safe allocators. @live is, unfortunately, completely useless.

[ichordev]

Move semantics and a unique(T) qualifier are the two language features that would help the most with @safe allocators.

DIP time!

@live is, unfortunately, completely useless.

Yeah, it seems unfinished.

[pbackus]

Yeah, it seems unfinished.

Unfortunately, the design of @live is fundamentally flawed. Because it assigns new meanings to existing language constructs (pointers, scope), @safe @live code and @safe non-@live code are mutually incompatible, and cannot interoperate without risking memory corruption. Adopting @live would create a Python 2/3-style split between existing @safe code and @safe @live code.

[ichordev]

Since @safe allocation/deallocation won't always be practical, I think it makes sense to have an @system variant. Safe should be the default, so I think a name like (de)allocateUnsafe makes sense for the @system interface.
Obviously the actual allocation function can always be @safe (only deallocating is inherently unsafe), but it wouldn't return a unique pointer like allocate.

[pbackus]

@system code can already do this by taking the void[] it wants to deallocate, manually constructing a Block from it, and passing that Block to deallocate.

Also, there's nothing stopping an allocator from having a @system deallocate method, if that turns out to be necessary or desirable in any particular case. The new design allows deallocate to be @safe, but does not actually require it.