More radical ideas about gc and reference counting

[H. S. Teoh via Digitalmars-d]

On Thu, May 01, 2014 at 02:29:22PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 5/1/14, 1:19 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Thu, May 01, 2014 at 01:03:06PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> >>On 5/1/14, 12:52 PM, "Nordlöw" wrote:
> >>>>>into a class. I'm inclined to say that we should outright
> >>>>>prohibit that,
> >>>>
> >>>>That can't happen.
> >>>
> >>>Why is that?
> >>
> >>(1) Too much breakage, (2) would disallow a ton of correct code, (3)
> >>no reasonable alternative to propose. We'd essentially hang our
> >>users out to dry. -- Andrei
> >
> >Isn't this what we're already doing by (eventually) getting rid of
> >class dtors?
> 
> Not even close. (1) A lot less breakage, (2) disallowed code was
> already not guaranteed to work, (3) reasonable alternatives exist.
[...]

Argh, I feel like this discussion is going in circles. Do I really have
to spell everything out just to make my point?

1) Today, a struct with a dtor will have the dtor invoked when the
struct goes out of scope.

2) Today, the language allows you to put such a struct in a class as a
member variable.

3) Today, the struct dtor of the class member will get invoked when the
class dtor is invoked.

4) Andrei is proposing to deprecate class dtors, meaning that at some
point they will no longer exist.

5) When that day comes, class dtors will no longer exist.

6) Since class dtors were the only thing that cleaned up the struct
member variables by invoking their dtors, that means the struct dtor
will *never* get invoked.

Since the struct dtor will *never* get invoked, it makes no sense to
define one in the first place. What's the point of defining a struct
dtor if there is no guarantee it will get invoked? That completely
defeats the purpose of a dtor. Do we really want D's dtors to have the
semantics of "this *might* get called with the struct is destroyed, or
it *might* not?" Then we might as well go back to C and do manual
cleanups.

And if Andrei's proposal to get rid of class dtors goes through, then
the only way to guarantee dtor semantics is to prohibit the use of
structs with dtors as class members. It's either that, or struct dtors
will be left in the limbo of "maybe it will get called, maybe it won't".
I don't see this as an advantageous position at all -- in fact, it's a
regression from the current language, which, as Walter demonstrated,
*does* invoke the struct dtor when the class goes out of scope.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL