RFC: moving forward with @nogc Phobos

[Cliff via Digitalmars-d]

On Wednesday, 1 October 2014 at 18:37:50 UTC, Sean Kelly wrote:
> On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
> Digitalmars-d wrote:
>>
>> 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.
>
> Assuming you're willing to take the memoryModel type as a
> template argument, I imagine we could do something where the 
> user
> can specialize the memoryModel for their own types, a bit like
> how information is derived for iterators in C++.  The problem is
> that this still means passing the memoryModel in as a template
> argument.  What I'd really want is for it to be a global, except
> that templated virtuals is logically impossible.  I guess
> something could maybe be sorted out via a factory design, but
> that's not terribly D-like.  I'm at a loss for how to make this
> memoryModel thing work the way I'd actually want it to if I were
> to use it.

If you were to forget D restrictions for a moment, and consider 
an idealized language, how would you express this?  Maybe 
providing that will trigger some ideas from people beyond what we 
have seen so far by removing implied restrictions.