D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

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