Open ryuukk opened 2 years ago
"Not touching the standard library" is an extremely asinine aim
"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
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.
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
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
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