On Sunday, 22 February 2015 at 17:01:45 UTC, Andrei Alexandrescu
wrote:
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.
What ??? That mean writing all library code twice, for client
that want GC and for these who don't. That is a looser strategy.
That means:
1. client code must not be able to declare variables of type C
or issue calls like "new C" etc.
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.
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.
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.
Sounds like a world class RC would not force all the code to be
written twice.
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 don't think we want to implement RC in the language, but
implement what would allow to have safe RC as library.
