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

[Stanislav Blinov via Digitalmars-d]

On Sunday, 7 May 2017 at 11:46:33 UTC, Andrei Alexandrescu wrote:

On 5/7/17 1:30 PM, Stanislav Blinov wrote:




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


Cool, thanks. Before we saw that, Eduard and I are working on a 
similar solution along the lines of IAllocator!(Flag!"nogc", 
Flag!"safe"). -- Andrei


I guess the exact representation of "traits" is something to 
decide on. I have to say, even though I used the BitFlags-based 
solution, I'm not a big fan of that, the syntax is a bit 
unwieldy. Then again, Flag-based would be too.

Perhaps a struct with enum members could be used...

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

[Andrei Alexandrescu via Digitalmars-d]

On 5/7/17 1:30 PM, Stanislav Blinov wrote:




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


Cool, thanks. Before we saw that, Eduard and I are working on a similar 
solution along the lines of IAllocator!(Flag!"nogc", Flag!"safe"). -- Andrei

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

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

[Atila Neves via Digitalmars-d]

On Monday, 1 May 2017 at 07:42:19 UTC, Sebastiaan Koppe wrote:

On Friday, 28 April 2017 at 22:18:54 UTC, Atila Neves wrote:
Done. I also added to the README that it has its own versions 
of the range constraints from Phobos that can be used with 
`@models`.


Atila


Example of an error message in the README would be great too.


Good point, done.

Atila

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

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/01/2017 10:51 PM, Stanislav Blinov wrote:

On Monday, 1 May 2017 at 16:31:10 UTC, Nick Sabalausky (Abscissa) wrote:


If we had a type similar to TaggedAlgebraic...

Destroy?


It's too strict: you have to specify concrete types beforehand.


No, that's why my suggestion was:

"If we had a type similar to TaggedAlgebraic, but was an open variant 
rather than a closed algebraic (Ie, a type like Phobos's Variant, but 
forwarded member access without first requiring explicit conversion to 
the exact underlying type),"

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

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 2 May 2017 at 02:51:02 UTC, Stanislav Blinov wrote:

Lost one else. Should be

 static if (traits & (AllocatorTraits.sharedInstance |
 AllocatorTraits.noGC))
 @nogc shared { mixin AllocatorInterface!(); }
 else static if (traits & AllocatorTraits.sharedInstance)
 shared { mixin AllocatorInterface!(); }
 else static if (traits & AllocatorTraits.noGC)
 @nogc { mixin AllocatorInterface!(); }
 else
 mixin AllocatorInterface!();

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

[Stanislav Blinov via Digitalmars-d]

On Monday, 1 May 2017 at 16:31:10 UTC, Nick Sabalausky (Abscissa) 
wrote:



If we had a type similar to TaggedAlgebraic...

Destroy?


It's too strict: you have to specify concrete types beforehand. 
This spills over into user code and makes it far less versatile 
that can be achieved.
Currently with allocators we have two extremes: IAllocator (and 
now, ISharedAllocator) that carries *no* static type information 
about concrete implementation, *and* loses all the inference 
regarding @nogc and shared memory. On the other end it's 
CAllocatorImpl that carries *both*.
But for user code, what is desirable is to have a middle man: a 
type that erases concrete allocator type but still keeps the 
@nogc and/or shared. This would enable user types to exchange 
their allocators while keeping static checks afforded by the 
language.

This can be done e.g. like this:

enum AllocatorTraits
{
none= 0x00,
noGC= 0x01,
sharedMemory= 0x02,
sharedInstance  = 0x04,
}

mixin template AllocatorInterface()
{
Ternary owns(Block block) @nogc;
Ternary resolveInternalPointer(void* p, ref Block result) 
@nogc;

Ternary empty() const @nogc;

Block allocate(size_t, TypeInfo ti = null);
Block alignedAllocate(size_t, uint);
Block allocateAll();
bool expand(ref Block, size_t);
bool reallocate(ref Block, size_t);
bool alignedReallocate(ref Block, size_t, uint);
bool deallocate(Block block);
bool deallocateAll();
}

template IAllocatorImpl(AllocatorTraits traits)
{
static if (traits & AllocatorTraits.sharedInstance)
alias Base = ISharedAllocator;
else
alias Base = IAllocator;

interface IAllocatorImpl : Base
{
static if (traits & AllocatorTraits.sharedMemory)
alias Block = shared(void)[];
else
alias Block = void[];

static if (traits & (AllocatorTraits.sharedInstance | 
AllocatorTraits.noGC))

@nogc shared { mixin AllocatorInterface!(); }
else static if (traits & AllocatorTraits.sharedInstance)
shared { mixin AllocatorInterface!(); }
else
@nogc { mixin AllocatorInterface!(); }

mixin AllocatorInterface!();
}
}

...and make the allocatorObject() function return 
IAllocatorImpl!traits instead of CAllocatorImpl!Allocator. With 
such IAllocatorImpl, user code can specify concrete expectations 
about the allocator without needing to know the exact allocator 
type.

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

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/30/2017 05:39 PM, Andrei Alexandrescu wrote:

The allocators design is interesting in that it has a full DbI core, on
top of which resides a thin dynamically-type interface (IAllocator and
ISharedAllocator). We're still exploring the idioms enabled by this
interaction. -- Andrei


I assume this dual-interface design (DbI + OO) is, much like std.digest, 
a way to have our template/DbI cake and still permit things to be 
selected at runtime too (via OO), right?


If so, this is a topic that's been on my mind lately, and I'd like to 
offer some thoughts I've had (well, some partial thoughts anyway):


Part A: While I like that the std.digest design allows both DbI and 
runtime-selection of arbitrary user-created types, it has a few issues:


1. It feels awkward that it needs essentially duplicate APIs under two 
different paradigms to pull it off.


2. If a library (such as mine) wants to support both versions, then it 
needs a little bit of extra plumbing to accommodate that. Or at least it 
seemed to in my case. (std.digest itself even has a little bit of extra 
plumbing because of it: WrapperDigest)


3. The OO version, being OO, does involve some type erasure.

Now, fast-forward to:

Part B: On a separate project, I've used Sonke's TaggedAlgebraic before 
. It's kind of interesting: 
It's much like Phobos's Algebraic, except it allows function/member 
forwarding to the current underlying value *without* having to 
explicitly check what the current value's type is (Don't recall offhand 
exactly how it handles members that don't exist on the current type, 
probably throws I guess, although I'd imagine it would be possible to 
statically disallow access to members known at compile-time to not exist 
in *any* of the possible underlying types. But I digress).


But then:

Part C: At the time, I saw TaggedAlgebraic's member-forwarding as a 
minor little convenience feature. But the other day I was working with 
some code that used and built upon std.digest, and something occurred to me:


If we had a type similar to TaggedAlgebraic, but was an open variant 
rather than a closed algebraic (Ie, a type like Phobos's Variant, but 
forwarded member access without first requiring explicit conversion to 
the exact underlying type), then *that* could be used to permit 
runtime-selection between arbitrary DbI types *without* the type-erasure 
and "duality" of adding in OO (or at least, less type-erasure anyway). 
Just maybe need the ability to filter the allowable types via a 
constraint (such as isBidirctionalRange, etc), and then, IIUC it should 
be possible for the variant-like supertype to qualify as an 
honest-to-goodness instance of the DbI interface. Voila: OO has been 
obsoleted.


Destroy?

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

[Andrei Alexandrescu via Digitalmars-d]

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

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

[Guillaume Piolat via Digitalmars-d]

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.

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

[Stanislav Blinov via Digitalmars-d]

On Monday, 1 May 2017 at 04:54:28 UTC, Andrei Alexandrescu wrote:

On 4/30/17 8:43 PM, Stanislav Blinov wrote:
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?


The allocator itself may be shared across threads...


But it is no different in case of memory. Allocator that 
allocates shared memory should either return shared(void)[] or 
have an explicit interface (allocateShared et al.), not just have 
the  "you may cast result of allocate() to shared" somewhere in 
the docs. We should let the language do the work it can, not send 
us to RTFM. Hence my earlier statement that more interfaces are 
needed, as one possible (albeit not pretty) solution.

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

[Sebastiaan Koppe via Digitalmars-d]

On Friday, 28 April 2017 at 22:18:54 UTC, Atila Neves wrote:
Done. I also added to the README that it has its own versions 
of the range constraints from Phobos that can be used with 
`@models`.


Atila


Example of an error message in the README would be great too.

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

[Andrei Alexandrescu via Digitalmars-d]

On 4/30/17 8:43 PM, Stanislav Blinov wrote:

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?


The allocator itself may be shared across threads, in which case its 
primitives need to be reentrant. -- Andrei

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

[Stanislav Blinov via Digitalmars-d]

On Monday, 1 May 2017 at 00:43:22 UTC, Stanislav Blinov wrote:


block_ = allocator_.allocate(T.sizeof);


Obviously, should be Block.sizeof, and


AllocatorInterface!AllocTraits allocator_;


should be AllocatorInterface!traits allocator_

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?

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

[Andrei Alexandrescu via Digitalmars-d]

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. Allocators 
must, however, distinguish between reentrant and non-reentrant calls to 
the allocation primitives.


With regard to whether the memory is collectable or not we need some 
more thinking.



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.



Thanks,

Andrei

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

[Andrei Alexandrescu via Digitalmars-d]

On 04/27/2017 07:12 PM, Moritz Maxeiner wrote:

On Thursday, 27 April 2017 at 20:04:32 UTC, Stanislav Blinov wrote:

On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5355

Andrei


And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...


Wasn't one major selling point of compile time introspection / duck
typing that we could stop using interfaces such... naming schemes?


The allocators design is interesting in that it has a full DbI core, on 
top of which resides a thin dynamically-type interface (IAllocator and 
ISharedAllocator). We're still exploring the idioms enabled by this 
interaction. -- Andrei

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

[Andrei Alexandrescu via Digitalmars-d]

On 04/27/2017 04:04 PM, Stanislav Blinov wrote:

On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5355

Andrei


And then we'd probably need INoGCAllocator and ISharedNOGCAllocator...


"shared" is a type qualifier essentially changing the type of the 
interface, so a separate interface is needed. For @nogc, simple variance 
is sufficient:


interface A
{
void fun();
}

class B : A
{
void fun() @nogc {}
}

That said, there are quite a few functions we should be able to qualify 
as @nogc from the get-go, e.g. empty, expand, alignment etc. Would you 
like to try a PR to that effect? Thanks!



Andrei

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

[Atila Neves via Digitalmars-d]

On Friday, 28 April 2017 at 18:04:06 UTC, jmh530 wrote:

On Friday, 28 April 2017 at 17:09:22 UTC, Atila Neves wrote:


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }


Atila


I remember you had posted about this last year. It looks like 
you've added some stuff on ranges to it recently...interesting.


You might want to include an example in the Readme.md of using 
the concept as a template constraint for a function. Maybe like


void callfoo(T)(T x)
if (isFoo!T)
{
x.foo();
}

Foo foo;
callfoo(foo);


Done. I also added to the README that it has its own versions of 
the range constraints from Phobos that can be used with `@models`.


Atila

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

[jmh530 via Digitalmars-d]

On Friday, 28 April 2017 at 17:09:22 UTC, Atila Neves wrote:


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }


Atila


I remember you had posted about this last year. It looks like 
you've added some stuff on ranges to it recently...interesting.


You might want to include an example in the Readme.md of using 
the concept as a template constraint for a function. Maybe like


void callfoo(T)(T x)
if (isFoo!T)
{
x.foo();
}

Foo foo;
callfoo(foo);

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

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/28/2017 01:09 PM, Atila Neves wrote:


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }



Hmm, close, but if I'm reading the source right, it looks like a type 
doesn't have to use the UDA in order for isXXX or "static 
assert(models..." to be satisfied, which was the whole issue I had. 
(Also, it'd be nice if it didn't require both isXXX and checkXXX to be 
manually written, because given a checkXXX function, the isXXX function 
is just boilerplate.)


Although I guess the checkXXX function could simply include a check the 
the UDA. Be nice if that was taken care of automatically though. Now if 
only we could get Phobos to do that...


I do, however, like the improved diagnostics this offers, and the fact 
that the checkXXX function uses a much saner (simpler, easier to 
read/remember/understand) syntax than the usual `is(typeof((){ ... })))` 
mess. I may use this.

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

[Atila Neves via Digitalmars-d]

On Friday, 28 April 2017 at 01:12:39 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 04/27/2017 07:12 PM, Moritz Maxeiner wrote:


Wasn't one major selling point of compile time introspection / 
duck
typing that we could stop using interfaces such... naming 
schemes?


Not that I speak for everyone, but the way I see it, no, the 
duck typing aspect is just something that's to be tolerated. 
The real gold is simply being freed from both the rigid mess 
and the runtime costs of class/interface hierarchies. I wish we 
DID have to include some kind of "implements ForwardRange" or 
"enum _thisStructImplements_ForwardRange" or some such to 
declare a type actually intends to be a ForwardRange (or 
whatever) and isn't merely qualifying as one by coincidence.


https://github.com/atilaneves/concepts

import concepts;

@models!(isForwardRange, MyType)
struct MyType {  }


Atila

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

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/27/2017 07:12 PM, Moritz Maxeiner wrote:


Wasn't one major selling point of compile time introspection / duck
typing that we could stop using interfaces such... naming schemes?


Not that I speak for everyone, but the way I see it, no, the duck typing 
aspect is just something that's to be tolerated. The real gold is simply 
being freed from both the rigid mess and the runtime costs of 
class/interface hierarchies. I wish we DID have to include some kind of 
"implements ForwardRange" or "enum _thisStructImplements_ForwardRange" 
or some such to declare a type actually intends to be a ForwardRange (or 
whatever) and isn't merely qualifying as one by coincidence.

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

[Stanislav Blinov via Digitalmars-d]

On Thursday, 27 April 2017 at 23:12:48 UTC, Moritz Maxeiner wrote:
On Thursday, 27 April 2017 at 20:04:32 UTC, Stanislav Blinov 
wrote:
On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei 
Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5355

Andrei


And then we'd probably need INoGCAllocator and 
ISharedNOGCAllocator...


Wasn't one major selling point of compile time introspection / 
duck typing that we could stop using interfaces such... naming 
schemes?


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


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.

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

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 27 April 2017 at 20:04:32 UTC, Stanislav Blinov 
wrote:
On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu 
wrote:

https://github.com/dlang/phobos/pull/5355

Andrei


And then we'd probably need INoGCAllocator and 
ISharedNOGCAllocator...


Wasn't one major selling point of compile time introspection / 
duck typing that we could stop using interfaces such... naming 
schemes?

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

[Stanislav Blinov via Digitalmars-d]

On Thursday, 27 April 2017 at 19:57:52 UTC, Andrei Alexandrescu 
wrote:

https://github.com/dlang/phobos/pull/5355

Andrei


And then we'd probably need INoGCAllocator and 
ISharedNOGCAllocator...