On Wed, Apr 30, 2014 at 04:33:23PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 4/30/14, 4:17 PM, H. S. Teoh via Digitalmars-d wrote: [...] > >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.
Which will stop working once class dtors are deprecated, yet you still allow putting File in a class member. > >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. No, allowing the user to specify a struct with a dtor, and put that struct in a class, and then saying "nyah nyah class dtors don't exist anymore so your struct will never destruct" -- *that* is bad decision making. At the very least, the compiler should complain loudly and clearly that structs with dtors should not be put inside a class. Isn't this what D philosophy is supposed to be? Things should *work* by default, and unexpected behaviour (dtor never gets called) should only happen when the user explicitly asks for it. > >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. [...] I thought D is here because we want to do better than that? T -- GEEK = Gatherer of Extremely Enlightening Knowledge