std.experimental.allocator

[ryuukk_]

On Sunday, 13 August 2023 at 11:44:50 UTC, IchorDev wrote:
> I feel like I can't possibly be the first to ask, but I 
> couldn't find any prior discussion of this:
> When is `std.experimental.allocator` going to be moved out of 
> `experimental`? Is there any roadmap for it? Is it just in 
> limbo?

We can and should do better than ``std.experimental.allocator``

It's unreadable and too complex, and it uses classes/interface 
therefore not good as a base

I also think this is not a job for phobos, i'd love to see the 
allocator stuff put in ``core.memory`

We only need 3 function pointers (allocate, free, resize), 
perhaps a struct that hold them

``core.memory`` only need 3 type of allocator: ``GCAllocator`` 
``PageAllocator`` ``ArenaAllocator``

In fact that's what i do, my core API is as simple as:

```D
struct VTable
{
     alloc_d alloc;
     resize_d resize;
     free_d free;
}

private alias alloc_d = ubyte[] function(const void* self, size_t 
len, ubyte ptr_align);
private alias resize_d = bool function(const void* self, ubyte[] 
buf, ubyte buf_align, size_t new_len);
private alias free_d = void function(const void* self, ubyte[] 
buf, ubyte buf_align);
```

I pass around a struct that has this vtable

```D
         heap = c_allocator;
         arena = ArenaAllocator.create(heap);

         servers.create(heap);
         entities.create(heap);

         // use arena for temp stuff
         // then clean it all in on go
         (..)
         arena.dispose();
```

No need to use classes or interface, a struct is all needed, 
effective, efficient and just few lines of code

Zig was eye opener to me, it should be as simple as possible, 
there is no reason to be complex or to use advanced features, the 
price to pay to use allocators should be 0, therefore it should 
work with -betterC

I am super interested in helping get stuff done, let's work 
together, ping me on the IRC server

More eye opening stuff:

https://www.gingerbill.org/series/memory-allocation-strategies/