RFC: moving forward with @nogc Phobos

[H. S. Teoh via Digitalmars-d]

On Tue, Sep 30, 2014 at 04:10:43PM +0000, Sean Kelly via Digitalmars-d wrote:
> On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu wrote:
> >
> >The policy is a template parameter to functions in Phobos (and
> >elsewhere), and informs the functions e.g. what types to return.
> >Consider:
> >
> >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;
> >}
> 
> Is this for exposition purposes or actually how you expect it to work?
> Quite honestly, I can't imagine how I could write a template function
> in D that needs to work with this approach.
> 
> As much as I hate to say it, this is pretty much exactly what C++
> allocators were designed for.  They handle allocation, sure, but they
> also hold aliases for all relevant types for the data being allocated.
[...]
> So... while I support the goal you're aiming at, I want to see a much
> more comprehensive example of how this will work and how it will
> affect code written by D *users*.  Because it isn't enough for Phobos
> to be written this way.  Basically all D code will have to take this
> into account for the strategy to be truly viable.  Simply outlining
> one of the most basic functions in Phobos, which already looks like it
> will have a static conditional at the beginning and *need to be aware
> of the fact that an RCString type exists* makes me terrified of what a
> realistic example will look like.

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.

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.

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. 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. 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.

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.

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


T

-- 
EMACS = Extremely Massive And Cumbersome System