On 12/12/2014 4:19 AM, Manu via Digitalmars-d wrote:
I simply do not understand why distinguishing beteen ref and not-ref is a
cornerstone of everything you do.
I've said so many times, it's the single greatest regular frustration
I encounter, by far.
That is of course a relative measure. It's not the 'cornerstone of
everything I do'; I don't start discussions about things that are not
broken and otherwise painless.
It is the thing that is *the most broken*, and leads to the most edge
cases, general bloat, and text mixins.
It comes up the most frequently, and by that metric alone, I consider
it highest priority on my list.
I've also said many times before, it possibly stems from the fact that
one of the key cornerstones of almost everything I do in D is interact
with other languages.
This is a practical reality, I can't write all my code in D, and have
mountains of existing code to interact with.
Boilerplate is the result. D has powerful systems to automate
boilerplate, like a carrot dangling right in front of my face, but
it's almost always thwarted by ref, and almost exclusively so.
My recent work updating LuaD to support all the features I required
wasted about 80% of my time dealing with ref issues.
In my past C++ bindings solutions, much code, which was otherwise
simple, readable, and elegant, turned into a mess of text mixins,
almost exclusively because ref is broken.
You've said this before, many times, but what is lacking is an explanation of
WHY. What is the pattern, and why do you need that pattern? You say you don't
like auto ref because it doesn't give you exact control, but what are the cases
where auto ref is wrong?
Consider a ref counted type, RC!T. If scope were transitive, then you could
not have, say, a tree where the edges were RC!T. I.e., the payload of an RC
type should not be forced to be scope.
I'm not sure I quite visualise this correctly...
struct Tree {
RefCount!(Tree*) left;
RefCount!(Tree*) right;
...
}
So you're saying that a pointer itself shouldn't be able to escape a
call tree, but the thing it points to should be able to escape just
fine?
Yes.
It feels like that kinda defeats the purpose...
You're arguing that a data structure with only one access point is the only kind
of data structure in use. With transitive scope, such a data structure would be
the only one possible!
I guess you're seeing a situation where 'scope' is almost exclusively
useful as a mechanism to tell the RC that it doesn't need to worry
about ref-fiddling, and the thing we're passing isn't interested in
scope restrictions at any level other than that RC optimisation?
I guess I can see your angle... but my reaction is if that's all you
are concerned about, maybe scope is the wrong tool for eliding ref
fiddling in that case :/
'scope' is a way to say that this use of a pointer does not escape this scope.
That is incredibly useful.
Recall my statements that pervasive refcounting is a terrible performance
problem because of all the inc/dec? Knowing that references cannot escape means
an inc/dec pair can be elided.
