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?
