>> into a class. I'm inclined to say that we should outright prohibit that,
>
> That can't happen.

Why is that?

/Per

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

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?

(Don't forget emplace'd class instances, which do not live in GC heap.)


T

-- 
Let's call it an accidental feature. -- Larry Wall

> (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

I misunderstood your usage of the word "can't". I thought it symbolized a practical/theoretical limitation, not design decision.

So to check if I got this right; class dtors will, with your proposal, only be called by the GC when any of its struct members has dtors, right?

For this to work the compiler will have to do some kind dtor inference of members, members of members etc, right?

On Thu, 01 May 2014 16:03:06 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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

class C
{
   void finalizer();
   private struct S {
     C owner;
     ~this() {
        owner.finalize();
     }
   }
   private S s;
}

You aren't helping anything.

-Steve

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.

Andrei

On 5/1/14, 2:04 PM, "Nordlöw" wrote:
> So to check if I got this right; class dtors will, with your proposal,
> only be called by the GC when any of its struct members has dtors, right?

No, in this proposal the GC heap would be entirely passive. Given the pushback in this thread that prolly won't fly.

Andrei

On 5/1/14, 2:21 PM, Steven Schveighoffer wrote:
> On Thu, 01 May 2014 16:03:06 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> 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
>
> class C
> {
>     void finalizer();
>     private struct S {
>       C owner;
>       ~this() {
>          owner.finalize();
>       }
>     }
>     private S s;
> }
>
> You aren't helping anything.

There's a misunderstanding somewhere. -- Andrei

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

On Thu, 01 May 2014 17:33:56 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 5/1/14, 2:21 PM, Steven Schveighoffer wrote:
>> On Thu, 01 May 2014 16:03:06 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> 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
>>
>> class C
>> {
>>     void finalizer();
>>     private struct S {
>>       C owner;
>>       ~this() {
>>          owner.finalize();
>>       }
>>     }
>>     private S s;
>> }
>>
>> You aren't helping anything.
>
> There's a misunderstanding somewhere. -- Andrei

The above is or is not allowed under the new proposal?

You said class dtors will cease to exist, but that you can have structs (with dtors?) embedded in them.

I defined a de-facto destructor for a class, when none is allowed. Unless you are planning on having classes not call the struct dtors?

-Steve