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
