std.experimental.allocator

[ryuukk_]

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.

Core API should subscribe to the premise: give memory allocation 
control (and therefore dealocation) back to the user

I'm not against you using RAII, however, i'm against making RAII 
a requirement for everyone who want to use the API

That's why i'm suggesting moving the API to ``core.memory``, you 
can have RAII based allocators in phobos ``std.memory``, it's 
more for general use

But ``core`` means it's the foundation, helps port to esoteric 
platforms easier, or usecases where RAII might not be the best 
choice / or not possible at all

Also if you want people to use D for games, you want an allocator 
API that doesn't use RAII, same for exceptions btw