More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 5/1/14, 3:22 PM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via Digitalmars-d 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. 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.
>
> Exactly!!! This is why I said we should ban the use of structs with
> dtors as a field in a class.

No.

> Isn't the D philosophy to be correct by
> default, and only allow potentially wrong/error-prone code if the user
> explicitly asks for it?

We can't propose correctness at the price of getting work done.

> So this kind of error-prone usage should not be
> allowed by default.  Was my logic really that hard to follow?

Your logic is flawed. I am sorry.


Andrei