On 5/1/14, 3:17 PM, H. S. Teoh via Digitalmars-d wrote:
> 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.

Here's where the point derails. A struct may be preexisting; the decision to define a destructor for it and the decision to use polymorphism for an object that needs that structure are most of the time distinct.

Andrei

On Thursday, 1 May 2014 at 22:18:59 UTC, H. S. Teoh via Digitalmars-d wrote:
[snip]
>
> 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.
[snip]

I might be mistaken but isn't it the case now that class dtors may never get invoked by the GC anyway? In which case having class dtors is pointless because one cannot rely on them.

But dtors for structs I thought would still be useful. The dtor might not be called by the class dtor as it no longer exists, but it is called if I reassign the struct member by value.

C c = new C();

// some code
auto s = SomeStruct(/*with some parms*/);
c.setStruct(s); // the existing c.struct dtor will be called, releasing whatever resources it needs


Cheers,
ed

On Thursday, 1 May 2014 at 02:36:23 UTC, Walter Bright wrote:
> On 4/30/2014 6:50 PM, deadalnix wrote:
>> On Thursday, 1 May 2014 at 01:20:37 UTC, Walter Bright wrote:
>>> A link to your previous comment would be useful.
>>
>> I've written several proposal regarding this. Please at least read them as what
>> you just wrote only proves you are not well informed.
>>
>> Notably, the proposal do not require annotations from the users to do the kind
>> of things are are currently being special cased.
>
> A link would be nice.

http://forum.dlang.org/thread/yiwcgyfzfbkzcavuqdwz@forum.dlang.org

Just made a new topic with code sample, so the idea can be grasped more easily (or so I hope).

On Thursday, 1 May 2014 at 20:03:03 UTC, Andrei Alexandrescu 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

(1) is made of turbo lol. A huge amount of binding to C++ lib rely on destructor. The breakage in the proposal is already massive. For instance, GtkD won't work. And other example have been presented.

On Friday, 2 May 2014 at 00:45:42 UTC, Andrei Alexandrescu wrote:
> Here's where the point derails. A struct may be preexisting; the decision to define a destructor for it and the decision to use polymorphism for an object that needs that structure are most of the time distinct.
>
> Andrei

Sheep eat grass.
Boat float on water.

These are completely distinct. Therefore, there won't be any issue if we ditch all the grass in the sea from that boat the carry sheeps around.

On Thursday, 1 May 2014 at 21:29:19 UTC, Andrei Alexandrescu 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.
>
> Andrei

I have 165k lines of code to review for that change... I would not call it a minor breakage...

/Paolo

On 5/2/14, 12:07 AM, deadalnix wrote:
> The breakage in the proposal is already massive. For instance, GtkD
> won't work. And other example have been presented.

Yah, prolly we can't go that far. -- Andrei

On 5/2/14, 1:34 AM, Paolo Invernizzi wrote:
> On Thursday, 1 May 2014 at 21:29:19 UTC, Andrei Alexandrescu 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.
>>
>> Andrei
>
> I have 165k lines of code to review for that change... I would not call
> it a minor breakage...

I didn't. I said a lot less that straight out disallowing struct members. -- Andrei

On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
> I think there's no need to argue that in this community. The GC never guarantees calling destructors even today, so this decision would be just a point in the definition space (albeit an extreme one).

I think I (we) need a bit of clarification.
Docs in http://dlang.org/class.html#destructors states that: "The garbage collector calls the destructor function when the object is deleted."
As far as I understand, this means that destructors are always called when an instance is collected. Is this right?
Doesn't this mean that destructors are guaranteed to run for unreferenced objects if we force the GC to do a full collect cycle?

On 5/2/14, 9:04 AM, fra wrote:
> On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
>> I think there's no need to argue that in this community. The GC never
>> guarantees calling destructors even today, so this decision would be
>> just a point in the definition space (albeit an extreme one).
>
> I think I (we) need a bit of clarification.
> Docs in http://dlang.org/class.html#destructors states that: "The
> garbage collector calls the destructor function when the object is
> deleted."
> As far as I understand, this means that destructors are always called
> when an instance is collected. Is this right?
> Doesn't this mean that destructors are guaranteed to run for
> unreferenced objects if we force the GC to do a full collect cycle?

False pointers make it seem like unreferenced objects are in fact referenced, so fewer destructors will run than there should. -- Andrei