Phobos 3 Discussion Notes - 02-01-2024

[Richard (Rikki) Andrew Cattermole]

On 07/02/2024 11:10 PM, Atila Neves wrote:
> On Wednesday, 7 February 2024 at 05:55:04 UTC, Paul Backus wrote:
>> On Tuesday, 6 February 2024 at 14:41:27 UTC, Martyn wrote:
>>> Curious to know how this will work for D. Will Allocators be 
>>> available for BetterC as well? I certainly hope so!
>>
>> Nothing's set in stone yet, but in the proposal I'm working on, there 
>> is nothing stopping allocators from being available in BetterC.
>>
>>> 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.
>>
>> 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.
> 
> 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.

I came to a similar conclusion from my usage of std.experimental.allocator.

My stuff doesn't use template parameters for things like memory allocators.

My conclusion was that you really only have two use cases for composable 
allocators:

1. You know about memory patterns, locking, type sizes ext. Use 
composable directly.
2. Otherwise, use virtual.

There doesn't seem to be anything in between.