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 <[email protected]> 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* >
