Phobos 3 Discussion Notes - 02-01-2024

[Jonathan M Davis]

On Wednesday, February 7, 2024 9:38:38 AM MST Paul Backus via Digitalmars-d 
wrote:
> On Wednesday, 7 February 2024 at 11:46:11 UTC, Richard (Rikki)
>
> Andrew Cattermole wrote:
> > My conclusion was that you really only have two use cases for
> > composable allocators:
> >
> > 1. You know about memory patterns, locking, type sizes ext. Use
> > composable directly.
> > 2. Otherwise, use virtual.
> >
> > There doesn't seem to be anything in between.
>
> The relevant constraint here isn't composability, it's safety.
>
> In order to make allocators @safe (which is the goal of my
> proposal), you have to guarantee somehow that memory blocks can
> only be deallocated by the same allocator that originally
> allocated them.
>
> It is possible to do this with a polymorphic allocator, but it
> incurs an enormous amount of runtime overhead, which rules out
> making it the default approach.
>
> Of course, if you don't care about @safe, you can ignore all of
> this and use a much simpler design. Personally, I think Phobos V3
> should support @safe as much as possible, but ultimately that
> choice is up to project leadership.

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

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. The templated ones would be more flexible with regards to
attributes and could be better optimized, whereas there could then be
virtual ones that wrapped those in classes but put harder requirements on
the attributes (be it by requiring more or allowing fewer), because they're
then supposed to work with most or all of the various allocator types. Then
both approaches would be available.

That being said, I would expect most D code to go with the templated
approach. It's what D typically does, and the kind of folks who want to use
allocators are usually also the kind of folks who aren't going to be very
happy about passing classes around.

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

- Jonathan M Davis