More radical ideas about gc and reference counting

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 30, 2014 at 03:55:38PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 4/30/14, 3:47 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
> >I don't like the sound of that. I haven't found myself in a place
> >where I needed to do something like this, but if I had to, I'd be
> >very unhappy if struct dtors only work when they're not class
> >members. Can we make them always work, and if necessary prohibit
> >using them as class members?
> 
> Then we're back to effectively class destructors. I think we've
> gathered quite a bit of evidence there are pernicious issues
> associated with them. -- Andrei
[...]

How so? If we prohibit structs with dtors from being class members,
then it could work. Of course, then you'd have to deal with the backlash
from users who inevitably find some use case for it... but at least in
theory it's possible.

But if we're going to go in the direction of lack of dtor guarantees,
then I might suggest we kill off struct dtors as well, since they also
have their own set of pathologies.  Like passing structs with dtors by
value (this includes returning them from a function) causing double
destruction if the dtor isn't written carefully, or putting structs with
dtors into an array or std.container.*, and they stop working as one
might expect.  Wasn't this whole fiasco the whole reason
std.stdio.ByLine was recently rewritten to use ref counting? It relied
on struct dtors before, and look how well that turned out.

Basically, you can't allow something to have dtors, yet have no way to
guarantee it will be called at the expected time. That kind of
under-specification is the source of endless hard-to-trace bugs,
gotchas, unfixable issues, and holes in the type system. If we're going
to have dtors at all, let's do it *right*. Guarantee they always work,
and reject all usages that break this guarantee (like putting a struct
with dtor inside a class, putting it inside a dynamic array in GC
memory, etc.). If we can't guarantee anything at all, then let's not
have dtors at all.  Trying to stay in the gray zone in between does
nothing but cause endless problems down the road. Not to mention
language smells. What's the use of a feature that only sometimes works,
where "sometimes" is un(der)specified, left to implementation, or
depends on undefined behaviour?


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi