What is the status of Weak References?

Owen ellbur at gmail.com
Thu Jul 20 22:26:59 UTC 2017

I see this is a very old thread, but I was wondering if there have been any
new developments/plans?

My thoughts are this:

I think it's natural, if you're used to seeing people misuse GC, to be
suspicious of weakrefs. With GC it's easy to create accidental memory leaks
because you think the useful lifetime of your objects will always
correspond to the lifetime of their references, when in fact they don't. My
Java code always has more memory leaks than my C++ code, even though they
tell me it shouldn't.

But in my experience people don't tend to misuse weakrefs. Weakrefs are
tricky and awkward, so they're not a tempting feature; people don't tend to
use them unless they have a specific compelling need. They're not a feature
like C++ implicit conversions where everyone uses them and then shoots them
in the foot. So I think the risk of adding weakrefs to the language from a
code maintainability perspective are fairly low.

I think the one-time-listener pattern is really great. I've written some
FRP code that uses it, and it makes a whole lot of things better, such as
skipping over unnecessary calculations and handling listeners that return
listeners gracefully. But it turns out it doesn't solve the memory problem
unless you also have weakrefs. The reason is that it's far more common than
you might think to create listeners that are never ever called. Think about
opening a dialog with OK and Cancel buttons, listening on each. Every time
you open the dialog, at least one listener will leak. What
one-time-listeners does solve very nicely is the lifetime of control -- you
can trust that the code associated with useless listeners will never be
called, and never waste CPU cycles. But unfortunately the memory stays
around unless you have weakrefs.

We must remember that our programming languages are Turing complete, so
that everything that can be done with weakrefs can also be done without
them. It might seem sort of like asking MS Paint to expose its flood-fill
algorithm through an API -- because you know it's in there, and maybe you
want to use it in your code and avoid duplication. Well, that would seem
rather silly, asking MS Paint to expose an API -- go use your own
flood-fill algorithm! And maybe that's what it seems like with the GC --
just because the GC is there, doesn't mean it has to make all its features
available to the programmer to do what they like with.

It's just that it happens that implementing GC is just such a massive and
tricky task, that it's just *so* *tempting* to use the GC that's already
there. It can solve certain problems for you so that you don't have to
solve them yourself. It doesn't solve every problem -- no software can --
but when it does solve one of your problems it solves it so beautifully.
And it's just so frustrating to know the code is right there under the
surface and you can't use it. Sure, maybe you should do the memory
management yourself. But if you could just get at those weakrefs..... then
you'd be in good shape.

In my experience there is a very small set of problems that really really
benefit from weakrefs. Most of the code you write will never encounter one
of those problems. But when you do hit one, it's so nice when the language
supports it. You write your weakref code carefully -- because it's
nondeterministic and hard to debug. You box it in real tight and get a
solid core that uses weakrefs just the way you need it. Then you expose it
as a library and never think about it again. You make sure the semantics of
your library never expose a nondeterministic variable -- those stay on the

The funny thing is that even when you keep your API fully deterministic,
the fact that it can use the GC's nondeterminism on the inside changes what
the external API can do. It's like how using a nonlinear electrical
component can change the set of linear transfer functions you can implement
at the boundary. And because everyone wants to work with nice APIs at the
boundary, there's very little temptation to abuse weakrefs.

Just some things to consider.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170720/9b42b53c/attachment.html>

More information about the es-discuss mailing list