Re: std.experimental.allocator

[ryuukk_ via Digitalmars-d-learn]

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