Interesting PRs: bringing type system legitimacy to shared allocators

[Stanislav Blinov via Digitalmars-d]

On Monday, 1 May 2017 at 13:00:27 UTC, Andrei Alexandrescu wrote:
> On 05/01/2017 08:12 AM, Guillaume Piolat wrote:
>> On Sunday, 30 April 2017 at 21:43:26 UTC, Andrei Alexandrescu 
>> wrote:
>>>
>>> A pass through the root allocators (Mallocator, GCAllocator 
>>> etc)
>>> figuring out what attributes could be meaningfully attached 
>>> would be
>>> welcome. The rest would rely on inference.
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> IAllocator being fully @nogc would be a comforting guarantee, 
>> as runtime
>> dispatch makes for lighter types.
>
> As I said (and am encouraging you to do this), this is achieved 
> through simple variance:
>
> interface INoGCAllocator : IAllocator {
>    ... override all methods here as @nogc ...
> }
>
> This is possible because a @nogc method may override one that 
> is not @nogc. @nogc being more restrictive it is contravariant 
> with no- at nogc.
>
> Also IAllocator should have a few @nogc methods to start with; 
> there's no reason e.g. for empty() to create garbage.
>
> Could you please initiate a PR?
>
>
> Andrei

To follow this discussion up, and in light of yesterday's 
Collections presentation at DConf, I though I'd go ahead and make 
a basic implementation of traits-based IAllocator.

You can find it here:

https://github.com/radcapricorn/alloctraits

It pretty much evades the shortcomings of IAllocator, alleviates 
the need for any additional interfaces (ISharedAllocator et al.), 
at the cost of making user code slightly more verbose. But that 
is a small price to pay if we want to benefit from the type 
system.
The current implementation lacks a few features of 
std.experimental.allocator (i.e. passing implementation by 
pointer), which are easy to add, I was just focused mainly on 
roughing out the design as the first step.

Anyone interested, feel free to comment, improve, bash, destroy...