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