D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Wednesday, 7 October 2015 at 15:30:17 UTC, Jonathan M Davis 
wrote:
> 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.

With DIP74, the ref counting is hard coded into the type itself. 
The intention of the original author of the class is inseparable 
from the code. The same is not true for a class that is simply 
"meant" to be used in a context where it has deterministic 
destruction.

So if I was a graphics programmer, and awake of this 
issue(deterministic destruction), I could open up a class and 
just look for opRelease() rather than having to try and reason 
about it's usage.


> The programmer is always going to have to be careful about 
> where they put an object that needs deterministic destruction.

Again, it's much easier to be careful about this when the 
author's intent is baked into the class.


> 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.

Since you're probably going to make me repeat myself anyways, I 
might as well get it out of the way ;)

Again, it's much easier to be careful about this when the 
author's intent is baked into the class.

      Bit