On 2/23/15 6:56 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <[email protected]>"
wrote:
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=?= <[email protected]>"
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.
That's not feasible. Code that assumes the class object will live
forever can simply do things that are not allowed to code that must
assume the object will go away at some determined point. Consider this
which I just posted:
class Widget
{
private char name[1024];
char[] getName() { return name[]; }
...
}
The typechecker must WHILE COMPILING WIDGET, NOT ITS CLIENT know whether
getName() is okay or not.
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.
Well I don't know of another way.
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.
So what do you propose instead? I am well aware of the disadvantages of
a solution that _works_. Do you have something better?
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?
Structs and slices can be implemented @safe-ly after the advent of
DIP25. It's classes that are the troublemaker.
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.)
That does awfully little to help. I'm telling things as they are. It's
difficult to disagree with e.g. "a refcounted class cannot be implicitly
convertible to Object and stay refcounted".
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.
Looking forward to your insights.
Andrei
