On Friday, 2 May 2014 at 21:12:12 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, May 02, 2014 at 09:03:15PM +0000, monarch_dodra via
Digitalmars-d wrote:
On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu
wrote:
>So now it looks like dynamic arrays also can't contain
>structs with
>destructors :o). -- Andrei
Well, that's always been the case, and even worst, since in a
dynamic
array, destructor are guaranteed to *never* be run.
Furthermore, given
the "append causes relocation which duplicates", you are almost
*guaranteed* to leak your destructors. You just can't keep
track of
the usage of a "naked" dynamic array.
This usually comes as a great surprise to users in ".learn".
It's also
the reason why using "File[]" never ends well...
This is why I'm unhappy with the way this is going. Current
behaviour of
structs with dtors is already fragile enough, now we're pulling
the rug
out from under classes as well. So that will be yet another
case where
dtors won't work as expected.
I'm getting the feeling that dtors were bolted on as an
afterthought,
and only works properly for a very narrow spectrum of use
cases. Rather
than expand the usable cases, we're proposing to reduce them
(by getting
rid of class dtors). I can't see *this* ending well either. :-(
Unfortunately, the rug they are standing is placed over a gaping
hole in the ground, metaphorically speaking, so it never was a
very stable situation to begin with. I'm not sure it makes sense
to put much effort into increasing the likelihood that
destructors are called, when we then _still_ can't guarantee it.
Better to acknowledge that it simply can't work (if that's the
case), and try to find a way to avoid these situations. For
example, we could statically forbid GC managed objects with
destructors (not classes, but _anything_ GC managed). That means
that calling new for these types, or allocating a dynamic array
of them, will be an error. Of course, an escape hatch needs to be
put in place. "isolated" might be a candidate.
