On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via Digitalmars-d wrote:
> Hello.
>
> as there is no possibility to doing GC allocations in class
> destructors, wouldn't it be nice to just force "@nogc" attribute on
> such dtors?

Classes don't have to be designed to be allocated on the GC heap. Class instances can be allocated on the stack, the C heap, or anywhere else.

> i know, i know, "this will break alot of code". i'm pretty sure that
> this will break alot of INVALID code, which better be broken at
> compile-time anyway.

There is potentially a plethora of valid code broken by such a change:

 * Classes designed to be used on the stack or other non-GC-heap memory locations.
 * Class destructors that never call a GC function, but @nogc was nevertheless not applied throughout the codebase, maybe because it was an old or poorly maintainable codebase.
 * Users using non-standard or modified GC implementations that don't have this restriction.
 * Classes in programs that have ripped out the GC to begin with, replacing `new` and other GC primitives with something else. This one is dubious, as from a language standpoint, `new` is exclusively intended for GC allocation.
 * Class destructors calling into functions that predictively have both an allocating and non-allocating path, thus cannot be @nogc but can be verified at the call-site to be @nogc. Arguably such functions are poorly designed and should be split into two layers.

> let's see how this proposal will be rejected. will there be some sane
> reasons, or only the good old song about "broken code"? make your bets!

D is a systems-programming language and should cater to a wide variety of use patterns, including users who wish to use classes in non-GC memory locations. Perhaps splitting class destructors into two separate concepts, a destructor and a finalizer, with the latter being @nogc, could be a more satisfactory solution. Alternatively, maybe we should anticipate a standard GC implementation (or one of several standard implementations, like Java and .NET do) that does not have this restriction.

On Friday, 23 January 2015 at 06:16:21 UTC, Jakob Ovrum wrote:
> Classes don't have to be designed to be allocated on the GC heap. Class instances can be allocated on the stack, the C heap, or anywhere else.

…and this is a badly typed design if you don't embed ownership in reference types.

But, GC should not call destructors, because classes using RAII will then fail.

> D is a systems-programming language and should cater to a wide variety of use patterns, including users who wish to use classes in non-GC memory locations.

There are way too many weaknesses in current D semantics to make it suitable for systems programming. By systems programming I mean programming that push the hardware to the limits and take advantage of hardware specific properties.

The fact that you cannot gracefully recover from low-memory conditions is a bad sign.

A good reason for not acquiring resources in destructors is that you can then throw exceptions and recover when you run out of resources. Which is important on high load and/or low memory devices.

> Perhaps splitting class destructors into two separate concepts, a destructor and a finalizer, with the latter being @nogc, could be a more satisfactory solution.

How about banning GC-allocation of classes with destructors?

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?

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.

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.

-Steve

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.
>
> -Steve

Summing up the arguments in this thread, I think the reasonable middle ground here would be for a compiler to throw a warning if dtor doesn't satisfy @nogc. I.e., compiler knows at compile time that something MAY and probably WILL go wrong; the code as of current GC implementation is then unsafe which should be reported to the user. This is much better than just silent obscure memory exceptions at runtime.

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.
>
> -Steve

This is as per spec :)

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

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.

On Fri, 23 Jan 2015 23:28:28 +0000, Matthias Bentrup wrote:

> If the program ends before the next GC the destructor is never called.
nope.

  class A {
    ~this () { import iv.writer; writeln("dtor"); }
  }

  void main () {
    auto n = new A;
    assert(0);
  }

this outputs "dtor".