std.experimental.allocator

[IchorDev]

On Sunday, 13 August 2023 at 16:00:51 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> Yeah you're right Ternary should probably be replaced, although 
> amazingly it has never caused problems so far.
>
> But I cannot agree about RAII. Its a valid tool for managing 
> lifetimes of memory allocators. Memory allocators must be able 
> to store per instance state and that state must not 
> accidentally die on you. If it does that is a great way to give 
> the user a very bad day.
>
> We are certainly aiming for different things, for instance I 
> don't trust my (future) users when it comes to memory safety. 
> So they get very well hand held in all aspects. Including 
> locking of RCAllocator internally and using RC there.
>
> But internally to API's if you need to optimize you'd use the 
> composable allocator structs directly, rather than the 
> expensive (in comparison) RCAllocator.

I have complicated feelings about all of this.
The current implementation is a bit confusing, but I think that's 
due to somewhat poor documentation that's overenthusiastic to 
explain the complicated inner-workings, which would only matter 
to you if you want to build your own allocator. For an average 
user, the API could be explained as "malloc + free, except 
they're type-safe and take a custom allocator as an argument":
```d
auto x = make!Type(someAllocator);
dispose(someAllocator, x);
```

I agree with ryuukk_ that it should really be a `core` submodule, 
and obviously work with BetterC (but maybe still using exception 
throwing if we're being a bit forwards-looking).
`std.experimental.allocator.building_blocks`—and some other 
modules like it—have a lot of good code that I think shouldn't 
just be thrown out: 
https://dlang.org/library/std/experimental/allocator/building_blocks.html
I agree that the "interfaces" of the allocators should be re-done 
without `class` or `interface`. Some of the interface functions 
are explicitly optional, which would work better with a `struct` 
and function pointers. For the non-optional stuff, that's an 
annoyance...