Enforced @nogc for dtors?

Orvid King via Digitalmars-d digitalmars-d at puremagic.com
Tue May 6 05:35:51 PDT 2014


I actually don't think finalizers are an issue in the GC, but I do
agree that there should be a way to ensure that a value is
deterministically finalized. The thing is though, that's currently
possible by simply declaring the value as a struct, unless it's been
heap allocated, in which case we do the best we can.

On 5/6/14, via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> On Monday, 5 May 2014 at 18:32:30 UTC, Brian Rogoff wrote:
>> On Monday, 5 May 2014 at 17:46:35 UTC, Orvid King via
>> Digitalmars-d wrote:
>>> Destructors and finalizers are the same thing.
>>
>> That is exactly the point that I am arguing against. That they
>> are confused in D (or 'unified', if you think is a good thing)
>> I accept, but I think it's a language design error, or at least
>> an unfortunate omission.
>
> Yes, if the compiler doesn't know the conceptual parent-child
> relationship. e.g.: the parent-connection may close before the
> child-transaction has flushed/commited. In order to prevent this
> you can introduce (or deduce if you have the semantics of
> ownership) parent-pointers from child to parent and only allow
> parent roots to have their destructors called. The result is that
> the parent-root-tree is not released until all destructible
> children are ready.
>
> Having class objects on a separate heap with finalizer support
> could be reasonable if the class construct is viewed as an
> application-level construct and not a system-level construct.
> With a dedicated finalizer datastructure you can record
> finalization dependencies at the cost of a heavier runtime.
>
> However, I think not calling destructors at all for GC memory is
> the better (more nimble) approach for a system level programming
> language.
>
> *shrug*
>


More information about the Digitalmars-d mailing list