What about AllocRef and SyncAllocRef?

[lachlansneff]

I feel like this would provide the most ergonomic solution for working with both single-threaded and multi-threaded collections.

For a stack allocator, you'd pass &mut A into the collection. For a collection like a shared hashmap, you'd use an allocator that supported concurrent allocations and pass in &A. AllocRef would be implemented for either &A and &mut A depending on if it was concurrent or not.

It's definitely possible I'm not seeing some downsides of this, but it seems like the best of both worlds to me.

See my reply lower down.

[TimDiekmann]

Sadly this isn't possible, I already tried that in the alloc-wg crate. When taking self, a Copy bound is needed on AllocRef, otherwise most collection wouldn't work without many alloc.clone(). Requiring Copy or Clone is not possible as &mut does not implement it.

[lachlansneff]

@TimDiekmann Yeah, I see. That is unfortunate. My other idea is that there could be two allocator traits, AllocRef and SyncAllocRef.

It'd look something like this:

pub unsafe trait SyncAllocRef: Sync + Send {
    fn alloc(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocErr>;
    unsafe fn dealloc(&self, ptr: NonNull<u8>, layout: Layout);
    // ...
}

unsafe impl<A> AllocRef for A where A: SyncAllocRef {
    fn alloc(&mut self, layout: Layout) -> Result<NonNull<[u8]>, AllocErr> {
        <Self as SyncAllocRef>::alloc(self, layout)
    }
    unsafe fn dealloc(&mut self, ptr: NonNull<u8>, layout: Layout) {
        <Self as SyncAllocRef>::dealloc(self, ptr, layout)
    }
}

Then, regular collections could just take an AllocRef and any allocator would work for them, and concurrent collections could explicitly take a SyncAllocRef.

It's explicit, idiomatic in all circumstances, and doesn't result in performance pitfalls.

[TimDiekmann]

The idea isn't new, but I totally forgot about this approach, thank you for bringing this back! However I think this should be discussed in #55. I close this in favor of the other issue.