Simpler and easy use, extend and read Allocator API for the standard library

[ryuukk]

Description

To make D more attractive as a system language, we need a better memory strategy, we have the GC for general use cases, but sometimes you need to be precise about your memory needs and manual memory management is therefore required

We already have std.experimental.allocator but it's been stuck in experimental for ages.. and it is quite complex to understand..

What if we could instead take inspiration from other languages, and make a super simple to understand/extend API

It doesn't rely on anything in the druntime (other than emplace)

It doesn't touch the standard library

It is compatible with betterC

It is perfect for people to use in their custom mini runtime

I took the opportunity to rewrite Zig's allocator API, and to be honest it looks much cleaner to use, it's short, and it doesn't rely on anything in the std, (only libc for the c_allocator, that's to be expected)

What are rough milestones of this project?

Finalizing the alignment story, and it's ready to ship!

How does this project help the D community?

It helps grow D as a system language, for people with specific memory needs

Recommended skills

Anyone with enough motivation

What can students expect to get out of doing this project?

The problem is already solved, it's not up for grabs, but it's just to gather some discussion

Point of Contact

Here is the perfect place to discuss about it

References

The work has started here, and is already usable! (need to finalize alignment stuff)

https://gist.github.com/ryuukk/e6e02960496c491b3370ddbd8841979f

[maxhaton]

"Not touching the standard library" is an extremely asinine aim

[ryuukk]

"Not touching the standard library" is an extremely asinine aim

Why? it allows people to pickup the work on the API and extend it on esoteric platforms

This allows me to use the same API on desktop (with phobos), and WebAssembly (with my custom runtime without phobos)

Having it glued with the std means you are stuck, i don't want people to get stuck! and i want people to be having a set of API that are portable and works everywhere with 0 dependencies

So they do not need to reinvent the wheel, or fork the std whenever they are stuck

To me it looks like a pragmatic and smart AIM

People who depend on phobos are stuck and can't target WebAssembly, making them loose time to jump on the WebAssembly train, they'll be too late!

While me, i am on it!

And 0 import from the STD = you maintain your insane compile speed D offers

[maxhaton]

The aim should be to make Phobos work on webassembly. The allocators are mostly templates so it's not like you have to do all that much.

[Herringway]

I'm not sure if it was obvious, but putting this in the standard library means you can't possibly use it without importing something from the standard library

[ryuukk]

I'm not sure if it was obvious, but putting this in the standard library means you can't possibly use it without importing something from the standard library

it allows to pick up the API without touching other pieces

it is healthy way to develop core APIs in my opinion

it is easier when it is time to port, you can do it incrementally instead of doing it all at once, phobos is stuck because you gotta do it all at once, wich is painful to do and takes time

and it is faster to compile, you don't pull in hidden module dependencies