RFC: moving forward with @nogc Phobos

[Andrei Alexandrescu via Digitalmars-d]

On 9/29/14, 10:19 AM, Dicebot wrote:
> On Monday, 29 September 2014 at 17:04:54 UTC, Andrei Alexandrescu wrote:
>>> Yes but neither decision belongs to library code except for very rare
>>> cases.
>>
>> You just assert it, so all I can say is "I understand you believe
>> this". I've motivated my argument. You may want to do the same for yours.
>
> I probably have missed the part with arguments :)

No problem, let me paste it again:

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

=================

> Your reasoning is not
> fundamentally different from "GC should be enough" but extended to
> several options from single one.

Where's RC in the "GC should be enough"?

> My argument is simple - one can't forsee everything. I remember reading
> book of one guy who has been advocating thing called "policy-based
> design", you may know him ;) Was quite impressed with the simple but
> practical basic idea - decoupling parts of the implementation that are
> not inherently related.

Totally. Then it would be great if you trusted the guy when he makes a 
judgment call in which reasonable people may disagree.

There are many memory /allocation/ policies but precious few memory 
/management/ policies. I only know "manual", "scoped", "reference 
counted", and "tracing" based on... the last 50 years of software 
development.

>> So you don't have an answer. And again you are confusing memory
>> allocation with memory management.
>
> Yes, sorry, I don't have an answer. Or time do deeply dive into the code
> unless it is really important or my direct responsibility.
>
> Unfortunately, I don't see an answer how your proposal fits our code
> either. Most of Sociomantic code relies on using arrays as ref arguments
> to avoid creating of new GC roots (no, we don't need/want to switch to
> ARC). This was several times called as the reason why Phobos in its
> current shape is largely unusable for out needs even when D2 switch is
> finished. I don't see how proposal in original post changes that.

Passing arrays by reference is plenty adequate with all memory 
management strategies. You'll need to wait and see how the proposal 
changes that, but if you naysay, back it up.


Andrei