On Wednesday, 11 February 2015 at 05:39:59 UTC, H. S. Teoh wrote:
On Wed, Feb 11, 2015 at 03:20:57AM +0000, weaselcat via
Digitalmars-d wrote:
[...]
I was just using RefCounted!T as one example of a major
headache I've
had with D.
[...]
Jakob Ovrum has just submitted a PR to make (the current
version of)
RefCounted reject interfaces, since currently it doesn't do that
correctly (it refcounts the reference to the interface rather
than the
target object).
Given this is the current situation, it would appear to me to
make
RefCounted work with class objects, "all" we have to do would
be to
specialize RefCounted for classes, use malloc to allocate the
necessary
space (plus the refcount, of course), and emplace() the class
object
onto that space. Right?
Of course, given that it has been ... oh, months? years? since
RefCounted issues have been addressed, I'm probably just
kidding myself
that there are no major monkey wrenches in the works that would
make the
above simplistic solution not work. And I'm not sure I really
want to
know... Not until I have an actual use case for RefCounted in
my own
code, anyway, since otherwise I wouldn't have any confidence
that I was
Biggest problem with RefCounted is that it is a struct. Thus it
is inherently incompatible with polymorphic world. It is
impossible to do reference counted exceptions without language
changes (Andrei had proposal about it but it seems to have
stalled). It may be possible but not obvious how to do referenced
counted interfaces (that point to reference counted classes). It
is unclear how one would write in an idiomatic manner a function
that accepts object instance without caring if it is GC or
ref-counted one (without resorting to templates).
