RFC: moving forward with @nogc Phobos

[Andrei Alexandrescu via Digitalmars-d]

On 9/30/14, 10:33 AM, H. S. Teoh via Digitalmars-d wrote:
> Yeah, this echoes my concern. This looks not that much different, from a
> user's POV, from C++ containers' allocator template parameters. Yes I
> know we're not talking about*allocators*  per se but about *memory
> management*, but I'm talking about the need to explicitly pass mmp to
> *every*  *single*  *function*  if you desire anything but the default. How
> many people actually*use*  the allocator parameter in STL? Certainly,
> many people do... but the code is anything but readable / maintainable.

The parallel with STL allocators is interesting, but I'm not worried 
about it that much. I don't want to go off on a tangent but I'm fairly 
certain std::allocator is hard to use for entirely different reasons 
than the intended use patterns of MemoryManagementPolicy.

> Not only that, but every single function will have to handle this
> parameter somehow, and if static if's at the top of the function is what
> we're starting with, I fear seeing what we end up with.

Apparently Sean's idea would take care of that.

> Furthermore, in order for this to actually work, it has to be percolated
> throughout the entire codebase -- any D library that even remotely uses
> Phobos for anything will have to percolate this parameter throughout its
> API -- at least, any part of the API that might potentially use a Phobos
> function.

Yes, but that's entirely expected. We're adding genuinely new 
functionality to Phobos.

> Otherwise, you still have the situation where a given D
> library doesn't allow the user to select a memory management scheme, and
> internally calls Phobos functions with the default settings.

Correct.

> So this
> still doesn't solve the problem that today, people who need to use @nogc
> can't use a lot of existing libraries because the library depends on the
> GC, even if it doesn't assume anything about the MM scheme, but just
> happens to call some obscure Phobos function with the default MM
> parameter. The only way this could work was if*every*  D library author
> voluntarily rewrites a lot of code in order to percolate this MM
> parameter through to the API, on the off-chance that some obscure user
> somewhere might have need to use it. I don't see much likelihood of this
> actually happening.

A simple way to put this is Libraries that use the GC will continue to 
use the GC. There's no way around that unless we choose to break them all.

> Then there's the matter of functions like parseJSON() that needs to
> allocate nodes and return a tree (or whatever) of these nodes. Note that
> they need to*allocate*, not just know what kind of memory management
> model is to be used. So how do you propose to address this? Via another
> parameter (compile-time or otherwise) to specify which allocator to use?
> So how does the memory management parameter solve anything then? And how
> would such a thing be implemented? Using a 3-way static-if branch in
> every single point in parseJSON where it needs to allocate nodes? We
> could just as well write it in C++, if that's the case.

parseJSON() would get a memory management policy parameter, and will use 
the currently installed memory allocator for allocation.

> This proposal has many glaring holes that need to be fixed before it can
> be viable.

Affirmative. That's why it's an RFC, very far from a proposal. I'm glad 
I got a bunch of good ideas.


Andrei