More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 5/1/14, 3:10 PM, Walter Bright wrote:
> On 5/1/2014 3:02 PM, H. S. Teoh via Digitalmars-d wrote:
>> I'm confused. Andrei's original proposal was to deprecate class dtors,
>> with the view to eventually getting rid of them altogether. If indeed
>> that's going to be the case, then wouldn't that mean that field dtors
>> won't be invoked either (because otherwise, how would you know when to
>> invoke a field dtor?)?
>>
>> Without a clear definition of who is going to clean up those fields and
>> invoke their dtors, it would seem to me that having fields with dtors in
>> a class (once class dtors no longer exist, according to Andrei's
>> proposal) will be a dangerous thing to do, since the very guarantee by
>> having a dtor in the first place (it will get called to clean up when
>> the struct goes out of scope) is broken. If so, what's the point of
>> having a dtor in the first place? It becomes no different from the
>> manual cleanup that you have to do in C.
>
> The thing is, GC is a terrible and unreliable method of managing
> non-memory resource lifetimes. Destructors for GC objects are not
> guaranteed to ever run.

Agree.

> If you do have struct with a destructor as a
> field in a class, you've got, at minimum, suspicious code and a latent bug.

Disagree. The simple matter here is that there's no "right" solution to 
counter what you deem as suspicious code.

For example, we have a File struct. It is entirely legitimate for 
someone to want to keep a File member variable in a class object. They 
take care of opening and closing it appropriately. Again, this is 100% 
legit code to want to write. Coming to them from the perspective "you 
are doing it wrong and there is no recourse for achieving what you need 
to do" strikes me as odd.


Andrei