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-@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...
