D 2015/2016 Vision?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 7 October 2015 at 11:21:04 UTC, Namespace wrote:
>> Well, except that then it's less obvious that an object is 
>> ref-counted and less likely that the programmer using it will 
>> realize that the object expects to have a deterministic 
>> lifetime. So, it might actually make the situation worse and 
>> make it so that programmers are more likely to get wrong. I 
>> don't think that it's clear at all that the situation will be 
>> better with regards to programmers getting it right if it's in 
>> the language. Maybe it will be, but maybe it won't.
>>
>> - Jonathan M Davis
>
> Well then, there is another solution: enable inheritance for 
> structs as well. Then we have polymorphie and deterministic 
> lifetimes. Of course we cannot expect too much magic. But an 
> example:

How does that solve anything? The problem is that some types need 
a deterministic lifetime, and no object whose lifetime is managed 
by the GC gets a deterministic lifetime. So, even if an object 
supports deterministic destruction, that stops working as soon as 
its put inside of something whose lifetime is managed by the GC. 
Whether the object with deterministic destruction has inheritance 
or not doesn't really matter, and whether it naturally has 
deterministic destruction or whether it has it because it's being 
used in smart pointer doesn't really matter. It's the fact that 
it was put in an object whose lifetime is managed by the GC that 
screws with things.

Even if D classes were identical to C++ classes, and we had no 
structs, the fact that we have a GC managing the lifetime of 
anything causes problems with any type that needs deterministic 
destruction.

What's needed is to have a smart pointer of some kind to manage 
the lifetime of objects on the heap that need deterministic 
destruction and then to have the programmer make sure that they 
do put any of such objects inside of an object whose lifetime is 
managed by the GC if they want the deterministic destruction to 
work. You can't get away from requiring the programmer to be 
smart about things here unless you simply have no GC (which then 
requires them to smart about other things), or any type with 
deterministic destruction simply isn't allowed to be on the GC 
heap, which is unnecessarily limiting, particularly since in many 
cases, it's perfectly okay to let objects that might normally be 
destroy deterministically to be destroyed at the GC's leisure.

std.typecons.RefCounted aside, it's quite possible as-is to 
implement smart pointers in D with structs, thus providing 
deterministic destruction for reference types. I don't know why 
RefCounted wasn't implemented to work with classes, and I don't 
know why Walter and Andrei think that something like DIP 74 is 
necessary to support ref-counting. I might have heard, but if so, 
I forgot. It probably comes down to a loophole somewhere in how 
structs are put together that makes it throw off the ref-count 
(maybe something to do with init values), but that's speculation 
on my part. Regardless, if we have a proper ref-counting 
mechanism for classes (built-in or not doesn't necessarily matter 
- it just needs to work), then the folks that need deterministic 
destruction with polymorphism get it. But they're always going to 
have be careful about having such objects on the GC heap due to 
the nature of garbage collection.

- Jonathan M Davis