More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 4/30/14, 4:17 PM, H. S. Teoh via Digitalmars-d wrote:
> 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,

That sounds like a compiler bug.

> or putting structs with
> dtors into an array or std.container.*,

What's wrong with that? std.container.Array should destroy things 
properly, if not that's a library bug.

> 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.

But ref counting IS destructors.

> Basically, you can't allow something to have dtors, yet have no way to
> guarantee it will be called at the expected time.

I don't think so - it's navigating close enough to the "so let's not use 
cars anymore" fallacy. There are plenty many situations in which dtors 
are working fabulously well, and throwing them away because we can't 
guarantee they'll work absolutely well seems bad decision making to me.

> 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?

A lot of other languages have such imperfections, and nobody raises a brow.


Andrei