RFC: moving forward with @nogc Phobos

[via Digitalmars-d]

Ok, here are my few cents:

On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu 
wrote:
> Back when I've first introduced RCString I hinted that we have 
> a larger strategy in mind. Here it is.
>
> The basic tenet of the approach is to reckon and act on the 
> fact that memory allocation (the subject of allocators) is an 
> entirely distinct topic from memory management, and more 
> generally resource management. This clarifies that it would be 
> wrong to approach alternatives to GC in Phobos by means of 
> allocators. GC is not only an approach to memory allocation, 
> but also an approach to memory management. Reducing it to 
> either one is a mistake. In hindsight this looks rather obvious 
> but it has caused me and many people better than myself a lot 
> of headache.

I would argue that GC is at its core _only_ a memory management 
strategy. It just so happens that the one in D's runtime also 
comes with an allocator, with which it is tightly integrated. In 
theory, a GC can work with any (and multiple) allocators, and you 
could of course also call GC.free() manually, because, as you 
say, management and allocation are entirely distinct topics.

>
> That said allocators are nice to have and use, and I will 
> definitely follow up with std.allocator. However, std.allocator 
> is not the key to a @nogc Phobos.

Agreed.

>
> Nor are ranges. There is an attitude that either output ranges, 
> or input ranges in conjunction with lazy computation, would 
> solve the issue of creating garbage. 
> https://github.com/D-Programming-Language/phobos/pull/2423 is a 
> good illustration of the latter approach: a range would be 
> lazily created by chaining stuff together. A range-based 
> approach would take us further than the allocators, but I see 
> the following issues with it:
>
> (a) the whole approach doesn't stand scrutiny for non-linear 
> outputs, e.g. outputting some sort of associative array or 
> really any composite type quickly becomes tenuous either with 
> an output range (eager) or with exposing an input range (lazy);
>
> (b) makes the style of programming without GC radically 
> different, and much more cumbersome, than programming with GC; 
> as a consequence, programmers who consider changing one 
> approach to another, or implementing an algorithm neutral to 
> it, are looking at a major rewrite;
>
> (c) would make D/@nogc a poor cousin of C++. This is quite out 
> of character; technically, I have long gotten used to seeing 
> most elaborate C++ code like poor emulation of simple D idioms. 
> But C++ has spent years and decades taking to perfection an 
> approach without a tracing garbage collector. A departure from 
> that would need to be superior, and that doesn't seem to be the 
> case with range-based approaches.

I agree with this, too.

>
> ===========
>
> Now that we clarified that these existing attempts are not 
> going to work well, the question remains what does. For Phobos 
> I'm thinking of defining and using three policies:
>
> enum MemoryManagementPolicy { gc, rc, mrc }
> immutable
>     gc = ResourceManagementPolicy.gc,
>     rc = ResourceManagementPolicy.rc,
>     mrc = ResourceManagementPolicy.mrc;
>
> The three policies are:
>
> (a) gc is the classic garbage-collected style of management;
>
> (b) rc is a reference-counted style still backed by the GC, 
> i.e. the GC will still be able to pick up cycles and other 
> kinds of leaks.
>
> (c) mrc is a reference-counted style backed by malloc.
>
> (It should be possible to collapse rc and mrc together and make 
> the distinction dynamically, at runtime. I'm distinguishing 
> them statically here for expository purposes.)
>
> 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;
> }
>
> On the caller side:
>
> auto p1 = setExtension("hello", ".txt"); // fine, use gc
> auto p2 = setExtension!gc("hello", ".txt"); // same
> auto p3 = setExtension!rc("hello", ".txt"); // fine, use rc
>
> So by default it's going to continue being business as usual, 
> but certain functions will allow passing in a (defaulted) 
> policy for memory management.

This, however, I disagree with strongly. For one thing - this has 
already been noted by others - it would make the functions' 
implementation extremely ugly (`static if` hell), it would make 
them harder to unit test, and from a user's point of view, it's 
very tedious and might interfere badly with UFCS.

But more importantly, IMO, it's the wrong thing to do. These 
functions shouldn't know anything about memory management policy 
at all. They allocate, which means they need to know about 
_allocation_ policy, but memory _management_ policy needs to be 
decided by the user.

Now, your suggestion in a way still leaves that decision to the 
user, but does so in a very intrusive way, by passing a template 
flag. This is clearly a violation of the separation of concerns. 
Contrary to the typical case, implementation details of the 
user's code leak into the library code, and not the other way 
round, but that's just as bad.

I'm convinced this isn't necessary. Let's take `setExtension()` 
as an example, standing in for any of a class of similar 
functions. This function allocates memory, returns it, and 
abandons it; it gives up ownership of the memory. The fact that 
the memory has been freshly allocated means that it is (head) 
unique, and therefore the caller (= library user) can take over 
the ownership. This, in turn, means that the caller can decide 
how she wants to manage it.

(I'll try to make a sketch on how this can be implemented in 
another post.)

As a conclusion, I would say that APIs should strive for the 
following principles, in this order:

1. Avoid allocation altogether, for example by laziness (ranges), 
or by accepting sinks.

2. If allocations are necessary (or desirable, to make the API 
more easily usable), try hard to return a unique value (this of 
course needs to be expressed in the return type).

3. If both of the above fails, only then return a GCed pointer, 
or alternatively provide several variants of the function (though 
this shouldn't be necessary often). An interesting alternative: 
Instead of passing a flag directly describing the policy, pass 
the function a type that it should wrap it's return value in.

As for the _allocation_ strategy: It indeed needs to be 
configurable, but here, the same objections against a template 
parameter apply. As the allocator doesn't necessarily need to be 
part of the type, a (thread) global variable can be used to 
specify it. This lends itself well to idioms like

     with(MyAllocator alloc) {
         // ...
     }

>
> Destroy!

Done :-)