On Friday, 23 January 2015 at 23:28:28 UTC, Matthias Bentrup
wrote:
> On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer
> wrote:
>> On 1/23/15 3:40 PM, deadalnix wrote:
>>> On Friday, 23 January 2015 at 13:12:44 UTC, Steven Schveighoffer wrote:
>>>> On 1/23/15 8:05 AM, Matthias Bentrup wrote:
>>>>> On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
>>>>>> On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad wrote:
>>>>>>> How about banning GC-allocation of classes with destructors?
>>>>>> Uh... what? ^__^
>>>>>>
>>>>>> Maybe just ban classes altogether then?
>>>>>
>>>>> No, don't ban them, that will break to much code. Just don't execute
>>>>> them. Any application that depends on destructors being called by the GC
>>>>> is broken in 9 out of 10 cases anyway.
>>>>
>>>> This is very wrong.
>>>
>>> This is as per spec :)
>>
>> No, spec says your dtor is not guaranteed to run for unreferenced memory. It doesn't say your destructor may not be run even when the memory is collected. In fact, it says "The garbage collector calls the destructor function when the object is deleted."
>>
>> But my real point is that depending on dtors being called by the GC is not broken 90% of the time.
>>
>> -Steve
>
> If the program ends before the next GC the destructor is never
> called.

when the runtime shuts down it calls a full collect on the GC.
I'm not sure if this is actually required as per the spec.

On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer
wrote:
> On 1/23/15 3:40 PM, deadalnix wrote:
>> On Friday, 23 January 2015 at 13:12:44 UTC, Steven Schveighoffer wrote:
>>> On 1/23/15 8:05 AM, Matthias Bentrup wrote:
>>>> On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
>>>>> On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad wrote:
>>>>>> How about banning GC-allocation of classes with destructors?
>>>>> Uh... what? ^__^
>>>>>
>>>>> Maybe just ban classes altogether then?
>>>>
>>>> No, don't ban them, that will break to much code. Just don't execute
>>>> them. Any application that depends on destructors being called by the GC
>>>> is broken in 9 out of 10 cases anyway.
>>>
>>> This is very wrong.
>>
>> This is as per spec :)
>
> No, spec says your dtor is not guaranteed to run for unreferenced memory. It doesn't say your destructor may not be run even when the memory is collected. In fact, it says "The garbage collector calls the destructor function when the object is deleted."
>
> But my real point is that depending on dtors being called by the GC is not broken 90% of the time.
>
> -Steve

You are right, on a literal point, but I think that what he was
saying was something like:

"Any application that depends on object being collected in a
collect circle as unreferenced, so that depends on destructors
are being called by the GC is broken in 9 out of 10 cases anyway"

I agree with aldanor about his argumentation that a warning would
be appropriate: it's a very common pitfall, and a pitfall that
simply cast a bad light on the language in newcomers' minds when
it occurs at runtime.
Also if a lint tool can catch it, we all are conscious of the big
effort that the community leaders are putting on picturing a
better language for newbies (please, no pun intended, really!)
--
Paolo

On Saturday, 24 January 2015 at 00:31:48 UTC, Paolo Invernizzi wrote:
>> But my real point is that depending on dtors being called by the GC is not broken 90% of the time.
>>
>> -Steve
>
> You are right, on a literal point, but I think that what he was

If the classes are written for RAII then the destructors have to be called in reverse order of the constructors. IIRC D does not guarantee this when you use the GC.

So to do it right there is a lot of GC overhead.

> be appropriate: it's a very common pitfall, and a pitfall that
> simply cast a bad light on the language in newcomers' minds when
> it occurs at runtime.

Yes:

https://www.google.no/search?q=InvalidMemoryOperationError

This is the first I've heard that allocating GC memory in a destructor will crash. That's an unexpected gotcha. I'd expect to be able to reliably do I/O or throw an exception.

Strategy 1. Fix the GC's limitation. (One fewer pitfall to baby-sit.)

Strategy 2. Have the compiler inform the programmer. (The compiler can't catch all bugs but it should do what it can. Arguably this is a GC bug, not mine.)

Strategy 3. Put bold warnings in the reference <http://dlang.org/class.html#destructors> and all tutorials. That's useful but insufficient. Programmers will carry assumptions from other programming languages. Even those who read the D reference won't all remember that detail when it matters.

Strategy 4. Accept such crashes. (No good. The D home page promises safety.)


On Saturday, 24 January 2015 at 15:04:47 UTC, Ola Fosheim Grøstad wrote:
> If the classes are written for RAII then the destructors have to be called in reverse order of the constructors. IIRC D does not guarantee this when you use the GC.
>
> So to do it right there is a lot of GC overhead.

Yes, but the usability question is what do programmers expect? How much do they assume before turning to the docs?

It's a big stretch to expect LIFO behavior from garbage collection. It's not a stretch to expect logging to work.

On Wednesday, 21 January 2015 at 20:32:14 UTC, Steven Schveighoffer wrote:
>> Actually there's nothing on the documentation about class destructors
>> [1] that warns about that specific issue of the current (and default) GC.
>>
>> [1] http://dlang.org/class.html#destructors
>>
>
> I think the docs are in need of updating there. It's not meant to be a secret that you cannot allocate inside a GC collection. I'll try to put together a PR.

Please do!

On Thursday, 22 January 2015 at 14:07:31 UTC, Steven Schveighoffer wrote:
> In the vast majority of cases, nobody adds a dtor, or they use dtors for their intended purpose (deallocating non-GC resources) and everything works fine. And the runtime catches any slips with an appropriate handling (abort instead of corrupt memory).

While you're writing that PR, would you clarify that "The destructor is expected to release any resources held by the object." means ***non-GC resources*** and that `new` will abort?

Also would you be so kind as to make a bolder warning that member refs to GC objects may be invalid? That's nasty and unexpected! (Java finalizers don't work like that.) [Nulling them out would be nicer for debugging...]

"This means that destructors cannot reference sub objects. This rule does not apply to auto objects or objects deleted with the DeleteExpression, as the destructor is not being run by the garbage collector, meaning all references are valid."

That wording contradicts the previous paragraph about "the delete expression ... [calls] ... the garbage collector calls the destructor immediately". Maybe something like "...not being run in a garbage collection..." would be better.

1. is the only viable plan.

On Sun, 25 Jan 2015 22:09:04 +0000, deadalnix wrote:

> 1. is the only viable plan.

...which, in turn, equals to "do nothing for another year or more". instead of issuing warning to inform people that what they doing NOW is bad. i'm pretty sure that people are very happy to know that their code will work somewhere in the future, but here and now is invalid, and compiler doesn't even try to warn 'em about that fact. reading all that regular questions about "InvalidMemoryOperation" is fun, after all.

On Monday, 26 January 2015 at 00:39:18 UTC, ketmar wrote:
> On Sun, 25 Jan 2015 22:09:04 +0000, deadalnix wrote:
>
>> 1. is the only viable plan.
>
> ...which, in turn, equals to "do nothing for another year or more".

We are waiting for your pull request.

On Mon, 26 Jan 2015 02:13:26 +0000, deadalnix wrote:

> On Monday, 26 January 2015 at 00:39:18 UTC, ketmar wrote:
>> On Sun, 25 Jan 2015 22:09:04 +0000, deadalnix wrote:
>>
>>> 1. is the only viable plan.
>>
>> ...which, in turn, equals to "do nothing for another year or more".
> 
> We are waiting for your pull request.

it was preliminary rejected, as i'm not interested in "fixing" GC (it's ok for me in it's current state), only in error/waning.

On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison wrote:
> This is the first I've heard that allocating GC memory in a destructor will crash. That's an unexpected gotcha. I'd expect to be able to reliably do I/O or throw an exception.
>
> Strategy 1. Fix the GC's limitation. (One fewer pitfall to baby-sit.)

I expect this to happen sooner rather than later. GC is currently a very hot topic, with several people working on different aspects of it (performance, preciseness...).

>
> Strategy 2. Have the compiler inform the programmer. (The compiler can't catch all bugs but it should do what it can. Arguably this is a GC bug, not mine.)

Might be worthwhile if we don't manage to remove the GC limitation before, say, 2.068. But it will also trigger some false positives. It's unfortunate that currently the class/struct distinction is tightly coupled with the memory management strategy.

>
> Strategy 3. Put bold warnings in the reference <http://dlang.org/class.html#destructors> and all tutorials. That's useful but insufficient. Programmers will carry assumptions from other programming languages. Even those who read the D reference won't all remember that detail when it matters.

Agreed.

>
> Strategy 4. Accept such crashes. (No good. The D home page promises safety.)

Strongly agreed. IMNSHO we should try hard to detect errors already at compile time, even if it means disallowing potentially harmless things. It's just that in this case, the right thing to do is to fix the GC (and make writeln @nogc). This btw also applies to the other problems destructors have, like that the order of destruction of objects referring to each other is undefined. The GC should try to zero all references that it knows are GC managed, and are no longer life, before calling the destructor.