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
