source/blog/posts/2009/04/guaranteed-finalization-support.rst

   1 Title: Guaranteed finalization support
   2 Tags: en, d, dgc, understanding the current gc, finalization, specs
   3
   4 There was some discussion__ going on about what I found in my `previous
   5 post`__. Unfortunately the discussion diverged a lot, and lots of people seems
   6 to *defend* not guaranteed finalization for no reason, or arguing that
   7 finalization is supposed to be used with RAII__.
   8
   9 __ http://www.digitalmars.com/d/archives/digitalmars/D/GC_object_finalization_not_guaranteed_88298.html
  10 __ http://proj.llucax.com.ar/blog/dgc/blog/post/-43101db1
  11 __ http://www.digitalmars.com/d/1.0/memory.html#raii
  12
  13 I find all the arguments very weak, at least for convincing me that the
  14 `current specs`__ are not broken (if finalizers shouldn't be used with objects
  15 with its lifetime determined by the GC, then don't let that happen).
  16
  17 __ http://www.digitalmars.com/d/1.0/class.html#destructors
  18
  19 The current specs allow a D implementation with a GC that don't call finalizers
  20 for collected objects **at all**! So any D program relying on that is actually
  21 broken.
  22
  23 Anyways, from all the possible solutions to this problem, I think the better is
  24 just to provide guaranteed finalization, at least at program exit. That is
  25 doable (and easily doable by the way).
  26
  27 I filed a `bug report`__ about this, but unfortunately, seeing how the
  28 discussion at the news group went, I'm very skeptic about this being fixed at
  29 all.
  30
  31 __ http://d.puremagic.com/issues/show_bug.cgi?id=2858
  32
  33 .. vim: set et sw=4 sts=4 :