On Sunday, 22 February 2015 at 17:01:45 UTC, Andrei Alexandrescu
wrote:
On 2/22/15 6:49 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
<schue...@gmx.net>" wrote:
No. There's also returning the reference from a member
function, storing
it in a passed-in reference (pointer, ref, out or slice), and
passing it
to other functions that in turn leak the reference, as well as
throwing
it. And leaking closures containing the reference.
That's all that I can think of now...
Consider
class C { ... client code ... }
alias T = RefCounted!C;
... more client code ...
For reference counting to work transparently, access to the
symbol "C" must be restricted. RefCounted obviously needs
access to it. Client code should never have access to it, even
in the definition of C.
That means:
1. client code must not be able to declare variables of type C
or issue calls like "new C" etc.
No, this would require the class to be specialized for
refcounting. But the memory management method needs to be the
client code's decision; it can decide to manage some instance by
refcounting, some by Unique!C, and leave others to the GC. The
class implementer shouldn't need to care about all that.
2. The type of "this" in methods of C must be RefCounted!C, not
C.
3. Conversions of C to bases of C and interfaces must be
forbidden; only their RefCounted!Base versions must be allowed.
These two points have undesirable consequences: All consumers
such objects need to be aware of the exact type, which includes
the management strategy (RC, Unique, GC). But this is a violation
of the principle of separation of concerns: a consumer shouldn't
need to have information about the management strategy, it should
work equally with `RefCounted!C`, `Unique!C` and bare (GC) `C`,
as long as it doesn't take ownership of the resource.
4. Returning references to direct members of C must be
restricted the same way they are for structs (see
http://wiki.dlang.org/DIP25). A GC class object does not have
that restriction.
This is only a partial solution that doesn't work efficiently
with anything other then value members. Slices, pointers and
classes require introducing an additional, useless indirection,
and that's not the only problem with it.
I think reference counting is an important component of a
complete solution to resource management. D should implement
world-class reference counting for safe code.
For 1-4 above, although I am a staunch supporter of
library-exclusive abstractions, I have reached the conclusion
there is no way to implement RC in safe code for D classes
without changes to the language. The more we realize that as a
community the quicker we can move to effect it.
I'm not sure this is what you're implying, but do you want to
restrict it to classes only? Why not structs and slices, too?
Of course I agree that a language change is necessary, but I'm
convinced what you suggest above is not the right direction at
all. (And I see that deadalnix has already replied and basically
said the same thing.)
In general, this and related proposals tend to limit themselves
on memory management (as witnessed by the importance that `ref`
and `@safe` play in them). This is too narrow IMO. A well
thought-out solution can be equally applicable to the broader
field of resource management.
