More radical ideas about gc and reference counting

[via Digitalmars-d]

On Friday, 2 May 2014 at 21:12:12 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Fri, May 02, 2014 at 09:03:15PM +0000, monarch_dodra via 
> Digitalmars-d wrote:
>> On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu 
>> wrote:
>> >So now it looks like dynamic arrays also can't contain 
>> >structs with
>> >destructors :o). -- Andrei
>> 
>> Well, that's always been the case, and even worst, since in a 
>> dynamic
>> array, destructor are guaranteed to *never* be run. 
>> Furthermore, given
>> the "append causes relocation which duplicates", you are almost
>> *guaranteed* to leak your destructors. You just can't keep 
>> track of
>> the usage of a "naked" dynamic array.
>> 
>> This usually comes as a great surprise to users in ".learn". 
>> It's also
>> the reason why using "File[]" never ends well...
>
> This is why I'm unhappy with the way this is going. Current 
> behaviour of
> structs with dtors is already fragile enough, now we're pulling 
> the rug
> out from under classes as well. So that will be yet another 
> case where
> dtors won't work as expected.
>
> I'm getting the feeling that dtors were bolted on as an 
> afterthought,
> and only works properly for a very narrow spectrum of use 
> cases. Rather
> than expand the usable cases, we're proposing to reduce them 
> (by getting
> rid of class dtors). I can't see *this* ending well either. :-(

Unfortunately, the rug they are standing is placed over a gaping 
hole in the ground, metaphorically speaking, so it never was a 
very stable situation to begin with. I'm not sure it makes sense 
to put much effort into increasing the likelihood that 
destructors are called, when we then _still_ can't guarantee it.

Better to acknowledge that it simply can't work (if that's the 
case), and try to find a way to avoid these situations. For 
example, we could statically forbid GC managed objects with 
destructors (not classes, but _anything_ GC managed). That means 
that calling new for these types, or allocating a dynamic array 
of them, will be an error. Of course, an escape hatch needs to be 
put in place. "isolated" might be a candidate.