Using private constructor with std.experimental.allocater:make

[Basile B via Digitalmars-d-learn]

On Monday, 2 May 2016 at 04:19:48 UTC, earthfront wrote:
> On Sunday, 1 May 2016 at 19:18:38 UTC, Basile B wrote:
>> CT make(CT, Alloc, A...)(auto ref Alloc al, A a)
>
> This works. Thank you. Good point about __ctor alone not being 
> sufficient.
>
>>     auto memory = al.allocate(size);
> ...     <snip>
>>     GC.addRange(memory.ptr, size, typeid(CT));
>
> Nit: "GC.addRange..." -- this attempts to clean memory 
> allocated manually.
>
>> The problem is that the template make and emplace() are 
>> **elsewhere** so they cannot see A.this() (== A.__ctor).
>>
>> A common way to fix this kind of problem is to make a template 
>> mixin with the template that has the visibility and to mix it 
>> in the current scope
>
> I guess this is the best workaround at the moment.
>
> There's a discontinuity between the GC and std.allocators.
> "new A(1)" works, because the GC has implicit private access to 
> classes.
> I would love to see allocators in wider use. Workarounds are an 
> obstacle to this.
>
> Possible solutions:
> * Emulate c++'s "friend" keyword somehow. D's rationale 
> eschew's this.
> * Somehow designate friendship via [selective] module import?
> * Secret upcoming solution from Walter/Andrei. Weren't they 
> discussing some sort of built in ref counting system?

Other solution: give "super powers" to the __traits()... used to 
inspect, like suggested in this bugzilla ticket: 
https://issues.dlang.org/show_bug.cgi?id=15371.

The worst with this problem is that it's extremely easy to fix in 
the compiler source code. But it's extremely hard to make people 
understand that this is a real problem.