RFC: moving forward with @nogc Phobos

Cliff via Digitalmars-d digitalmars-d at puremagic.com
Wed Oct 1 12:23:44 PDT 2014


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.


More information about the Digitalmars-d mailing list