On Wednesday, 7 October 2015 at 12:59:05 UTC, bitwise wrote:
On Wednesday, 7 October 2015 at 09:49:27 UTC, Marc Schütz wrote:
RefCounted isn't implemented for classes, but there's no
reason why it shouldn't work.
Really, I don't get why everyone wants to have builtin
refcounting, when all that's required is a working way to make
escape-proof references.
If you make a class that owns a resources that needs
deterministic destruction, there is no guarantee that everyone
will wrap that class in a RefCounted properly. Also, I've
already stated many more problems with struct wrappers.
Except it doesn't even matter if they always wrap it properly -
or even if something like DIP 74 is implemented. The core problem
is that no object (be it struct or class) which needs
deterministic destruction can have its lifetime managed by the GC
- be it be simply being directly allocated by the GC or by
sitting inside of an object that was put on the GC heap without
any kind of ref-counting. The programmer is always going to have
to be careful about where they put an object that needs
deterministic destruction. They either have to keep it out of
objects whose lifetimes are managed by the GC or be okay with
them not actually being destroyed deterministically in that
particular case. The method of ref-counting doesn't change that.
That's simply a restriction of dealing with the GC. The only way
around that would be to make it illegal to put any kind of object
with a destructor (rather than a finalizer) on the GC heap, which
would be unnecessarily restrictive, particularly since there are
plenty of cases where a programmer isn't going to care that an
object that is normally destroyed deterministically ends up being
destroyed at the GC's leisure instead. Rather, if we don't want
to be stuck with techniques that Java and C# programmers use to
solve these problems, we need a way to provide deterministic
destruction for the programmer to use when they want to. Structs
get that natively. Classes don't.
So, for classes to be able to work with deterministic
destruction, we either need to have RefCounted (or something
similar) work properly with classes, or we need something like
DIP 74 which builds it into the language. It really doesn't
matter which it is so long as it works. My guess is that
RefCounted doesn't work with classes because of the fact that it
uses alias this, and alias this off the table if you're trying to
make it so that the wrapped object can't escape - though with
that in mind, I question that RefCounted to should have alias
this even it doesn't involve classes. opDispatch would be our
only hope at that point, and I don't know if that would fully
work or not (which may be why Walter and Andrei now are looking
at putting ref-counting into the language rather than getting it
to work with smart pointers like they were arguing for before).
Regardless of the ref-counting mechanism though, you can't
guarantee that it's going to be used correctly. The best that we
can do is guarantee that if it is used correctly, then the object
will be destroyed deterministically.
- Jonathan M Davis
