forcing "@nogc" on class destructors

[Jakob Ovrum via Digitalmars-d]

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.