Re: Interesting PRs: bringing type system legitimacy to shared allocators

[Stanislav Blinov via Digitalmars-d]

On Sunday, 30 April 2017 at 21:43:26 UTC, Andrei Alexandrescu 
wrote:
On 04/27/2017 07:35 PM, Stanislav Blinov wrote:
IAllocator is too high level an interface, it doesn't carry any
information as to what type of memory it can allocate (so we 
can only
assume unshared), and does or does it not use GC (so we can 
only assume
GC).

Initially all fresh memory is unshared. Whether or not the user 
subsequently shares it is of no consequence to the allocator.

Why would we need any ISharedAllocator then? If we're to force 
users to rely on *documentation* whether or not they can cast 
allocated memory to shared, there is no point in static checks, 
they'll only get in the way of user's attempts to try and stitch 
together the pieces. They're on their own anyway at that point.

If we are to devise types with allocators as members instead 
of type
arguments, we need the additional information. Better to catch 
invalid
assignment at compile time than to chase down how a stack 
allocator from
one thread ended up in another.

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.

If we're type-erasing allocators, we have to have the ability to 
statically specify what traits we're interested in (i.e. *don't* 
want to erase). Otherwise, inference will not be of any help.
Consider an example, inspired by the discussion of Atila's 
automem library:

import std.experimental.allocator;
import std.algorithm.mutation : move;

// Allocator is not a type parameter
struct SmartPtr(T)
{
    // we can infer all we need form A...
    this(A, Args...)(A alloc, auto ref Args args)
    if (isAllocatorImpl!A)
    {
        // ...but we immediately throw the inference away:
        allocator_ = alloc;
        block_ = cast(Block[])allocator_.allocate(Block.sizeof);
        // SmartPtr logic snipped...
    }

    ~this()
    {
        // ...SmartPtr logic snipped
        allocator_.deallocate(block_);
    }

private:
    struct Block
    {
        size_t refCount;
        void[T.sizeof] payload;
    }

    Block[] block_;
    IAllocator allocator_;
}

struct Data {
    ~this() @nogc { /*...*/ }
    // the rest of implementation is @nogc as well
}

struct MyType
{
    // won't compile: IAllocator's methods aren't @nogc,
    // so SmartPtr's dtor isn't either
    this(SmartPtr!Data data) @nogc
    {
        data_ = move(data);
    }

private:
    SmartPtr!Data data_;
}

Obviously, IAllocator is not the tool for the job here. This 
calls for something like this:

enum AllocTraits
{
    none  = 0x00,
    nogc  = 0x01,
    share = 0x02
}

alias AllocatorInterface(AllocTraits) = // ???

struct SmartPtr(T, AllocTraits traits = AllocTraits.none)
{
    this(A, Args...)(A alloc, auto ref Args args)
    {
        // this should not compile if A isn't compatible
        // with `traits`:
        allocator_ = alloc;
        block_ = allocator_.allocate(T.sizeof);
        // SmartPtr logic snipped...
    }

    ~this()
    {
        // ...SmartPtr logic snipped
        allocator_.deallocate(block_);
    }

private:
    void[] block_;
    AllocatorInterface!AllocTraits allocator_;
}

alias DataPtr = SmartPtr!(Data, AllocTraits.nogc);

struct MyType
{
    this(DataPtr data) @nogc
    {
        data_ = move(data);
    }

private:
    DataPtr data_;
}

That *would* be able to rely on inference. Question is, what is 
AllocatorInterface? Should we push such type erasure to the users?