Phobos 3 Discussion Notes - 02-01-2024

[Paul Backus]

On Wednesday, 7 February 2024 at 22:00:49 UTC, Jonathan M Davis 
wrote:
> Allocators should be @safe where they can be, but I think that 
> a number of us came to the conclusion a while ago that they 
> couldn't be @safe in the general case. So, it'll be interesting 
> to see what you can come up with, but if @safe is a 
> requirement, I would expect that certain kinds of allocators 
> simply won't work. But that's no reason not to support @safe as 
> much as possible (particularly when code is templated).

With -preview=dip1000 and -preview=systemVariables, it is 
possible to make pretty much any allocator @safe--although for 
some of them, the safety checking adds a little bit of runtime 
overhead.

The main obstacle is that both of these -preview features are 
still very much unfinished, and will need a lot of work before 
they are ready to be used in real library code.

By the way, one of the key techniques that makes this work is 
having the allocators wrap each void[] they return in a 
non-copyable struct, so that it can only be deallocated once. So 
you can probably understand why I'm so concerned about support 
for non-copyable types in Phobos v3. :)

> But with regards to virtual vs templated, we don't necessarily 
> have to decide in that we could design allocators so that they 
> can be used with either approach.

Yes, that's the idea.

> And based on both what has historically been done with 
> containers in D and the few discussions that we've had on it 
> recently, I expect that they're very much going to be taking 
> the Design by Introspection approach and be templated based on 
> their capabilities (of which the allocator would be only one, 
> though one of the possible approaches there is for one of the 
> options be to choose between a statically chosen alocator and a 
> dynamically chosen one).

This is also how I'd expect containers to work.