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
