Mine (-betterC) https://github.com/Project-Sidero/basic_memory/tree/main/source/sidero/base/allocators

Similar scope to one in Phobos.

On that note I'm still waiting a year+ for Atila to get back to me about talking about where to go for std.experimental.allocators.

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.

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

On 14/08/2023 4:10 AM, ryuukk_ wrote:
> Also if you want people to use D for games, you want an allocator API that doesn't use RAII, same for exceptions btw

After thinking about it a bit, this would suggest to me that you are trying to solve a problem that I would outright recommend against using an abstraction to solve.

Memory allocators that only deal with fixed sized memory blocks, that are specific to a thread are going to have the best performance. If this is the case you don't need an abstraction at all.

A rough pseudo code where no RCAllocator would be used:

```d
module particles;

private __gshared FreeList!(AllocatorList!(Region!(SystemMapper, __traits(classInstanceSize, Particle)))) allocator;

final class Particle {
	int lifeLeft;

	void free() {
		allocator.dispose(this);
	}

	static Particle create() {
		return allocator.make!Particle();
	}
}
```

Of course you'd only call free/create as part of a particle manager, but this should still demonstrate that an abstraction isn't required if you understand your data and memory lifetimes well enough to see any performance improvement by using a memory allocator library.

On Sunday, 13 August 2023 at 16:10:32 UTC, ryuukk_ wrote:
>
> Core API should subscribe to the premise: give memory allocation control (and therefore dealocation) back to the user
>

I'm not sure about why RAII is an issue, but I fully agree with your stance about a simpler allocator, and one we can actually build upon.

Great many C libraries work with just 3 preprocessor macros for malloc, free, realloc, something like that. A standard struct with 3 pointers in druntime would be great!

We just can't build upon std.experimental.allocator if it doesn't work in betterC and WebASM.

And it should be clear by now that D programmers want dependencies with fewer files, fewer concepts, fewer new names, (and if I may less templatitis) else they won't build upon it.