RFC: moving forward with @nogc Phobos

[Kiith-Sa via Digitalmars-d]

On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Wed, Oct 01, 2014 at 02:51:08AM -0700, Andrei Alexandrescu 
> via Digitalmars-d wrote:
>> On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
>> >29-Sep-2014 14:49, Andrei Alexandrescu пишет:
>> >>auto setExtension(MemoryManagementPolicy mmp = gc, R1, 
>> >>R2)(R1 path, R2
>> >>ext)
>> >>if (...)
>> >>{
>> >>     static if (mmp == gc) alias S = string;
>> >>     else alias S = RCString;
>> >>     S result;
>> >>     ...
>> >>     return result;
>> >>}
>> >
>> >Incredible code bloat? Boilerplate in each function for the 
>> >win?
>> >I'm at loss as to how it would make things better.
>> 
>> Sean's idea to make string an alias of the policy takes care 
>> of this
>> concern. -- Andrei
>
> But Sean's idea only takes strings into account. Strings aren't 
> the only
> allocated resource Phobos needs to deal with. So extrapolating 
> from that
> idea, each memory management struct (or whatever other 
> aggregate we end
> up using), say call it MMP, will have to define MMP.string, 
> MMP.jsonNode
> (since parseJSON() need to allocate not only strings but JSON 
> nodes),
> MMP.redBlackTreeNode, MMP.listNode, MMP.userDefinedNode, ...
>
> Nope, still don't see how this could work. Please clarify, kthx.
>
>
> T


MMP.Ref!redBlackTreeNode ?

(where Ref is e.g. a ref-counted pointer type (like RefCounted 
but with class support) for RC MMP but plain GC reference for GC 
MMP, etc.)

I kinda like this idea, since it might possibly allow 
user-defined memory management policies (which wouldn't get 
special compiler treatment that e.g. RC may need, though).