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