On Monday, 5 February 2024 at 16:46:20 UTC, Paul Backus wrote:

That just adds a singluar blessed environment, it will be very very unlikely that it will compile on wasm, a new embedded chip that releases in 2025, bsd, or a new rust os in 2040.

Which is a potential option but it's not a mythical "pay-as-you-go" and then you'll see nogc avocates being like "oi I needed to import toStringz but your (algorthim thats 100x simplier with allocation) allocates and broke my code, because of a 9 long import chain of unused code"

https://www.youtube.com/watch?v=a-767WnbaCQ

"just do ___"; no we are not even close to the phase change point, I suggest someone needs an answer for how you reduce the fundamental "order"/R0 of imports, which I think is 2 imports per file, or being extremely strict about local imports being in templates so they dont compile if unused

On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:

Very interesting!

I really like the Allocator idea. Something I think will benefit D and is overdue if being honest.

Curious to know how this will work for D. Will Allocators be available for BetterC as well? I certainly hope so!

If so, I guess the default Allocator will be the GC one, and can still be disabled. Being able to change the default (or change locally like in a function or pass it as parameter) would provide a lot of flexibility.

It's just I see possiblities of BetterC being able to use certain features that are not available, like dynamic or associative arrays. To be designed for allowing us to specify the Allocator to use (or default if not specified at all) and it doesn't need to be a GC one gives the programmer a lot of control for low level as well as high.

On Tuesday, 6 February 2024 at 14:41:27 UTC, Martyn wrote:

Nothing's set in stone yet, but in the proposal I'm working on, there is nothing stopping allocators from being available in BetterC.

In my proposal, when you use a library container (like an array, a hash table, a binary tree, etc.), you can specify what type of allocator you want to use as a template parameter (as in, Array!(int, GC)). It will probably default to the GC, but you can just as easily use malloc, or even a custom allocator that you write yourself.

I'm not planning to include a global default allocator. Built-in language features like new, dynamic arrays, associative arrays, and delegate contexts will always use the GC, and there will not be an option to change this.

On Wednesday, 7 February 2024 at 05:55:04 UTC, Paul Backus wrote:

Thank you for taking the time to respond. I understand a proposal is working on, but your answers above sound very promising. Thanks again.

On Wednesday, 7 February 2024 at 05:55:04 UTC, Paul Backus wrote:

The problem with this approach, as C++ found out, is that Vector!(int, MyAlloc) is a different type from Vector!(int, YourAlloc). The way I got around that is by defaulting to a global allocator. This has its drawbacks as well of course, because now everything is a virtual call.

On Wednesday, 7 February 2024 at 10:10:27 UTC, Atila Neves wrote:

I do that as well

struct Array(T)
{
    T[] items;
    Allocator allocator;
    size_t count = 0;

Just store the allocator in the struct, it's no big deal, granted your allocator type is a simple and compact struct

struct Allocator
{
    void* ptr;
    AllocatorFN* fn;
}
struct AllocatorFN
{
    alloc_d alloc;
    resize_d resize;
    free_d free;
}

// libc
enum c_allocator = Allocator(null, &CAllocator.fn);
struct CAllocator
{
    __gshared AllocatorFN fn = {
        alloc: &alloc_impl,
        resize: &resize_impl,
        free: &free_impl
    };
}

That's it

Allocator heap = c_allocator;

auto entities = Array!(Entity).create(heap);

On Wednesday, 7 February 2024 at 10:10:27 UTC, Atila Neves wrote:

Yes, I'm aware of this problem, but I don't see a way around it.

The thing is, the compiler has to know what allocator you're using at compile time in order to infer the correct function attributes for the container. If you want Array!int to default to using the GC, but also work in @nogc code when you're using malloc...how would that even work?

I have two potential mitigations for this problem in mind.

The first is to realize that D already has a solution for writing data-structure-agnostic code: ranges! If Array implements all of the relevant range interfaces, the rest of your code doesn't have to depend on any single concrete Array type--it can just depend on the range interface.

If you really need a concrete type, there's always std.range.interfaces, although that does come with some sacrifices (virtual calls, not @safe or @nogc, etc.).

The second is to have the allocator library provide a runtime-polymorphic allocator, which users can depend on if they absolutely need a single concrete container type for whatever reason. We'd have to make some serious tradeoffs between runtime overhead and attribute compatibility, and it's possible that no one-size-fits-all solution exists, but in principle, it can be done.

Finally, on the subject of global allocators: I don't think having a global allocator is a good idea, period, whether it's used as a default or not. Containers generally cannot tolerate having their allocators mutated "behind their backs," and a user-accessible global variable would make it very easy and tempting to write code that does this.