More radical ideas about gc and reference counting

[H. S. Teoh via Digitalmars-d]

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