More radical ideas about gc and reference counting

[H. S. Teoh via Digitalmars-d]

On Sat, May 03, 2014 at 11:12:36AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
[...]
> Anyhow, just to clarify, it seems like eliminating destructor calls
> during GC is not a viable option. I'll define std.allocator to allow
> users to define such a GC if they so want, without prescribing either
> policy.
[...]

Thank you. ;-)

On that note, it would be very nice if we could clearly define when dtor
calls will / will not happen. As someone else said, to an end-user of D
it is hard to accept that basic language constructs like arrays and
dtors, when used together, fail to function in an expected way (without
understanding what goes on underneath the hood, e.g. why dtors of array
elements may not get called). Ideally, the language should be designed
such that these obvious combinations of language constructs should
either Just Work(tm), or not be allowed, or require explicit annotation
(so that the user knows something unexpected might happen).

But, since we're not in an ideal world, the very least we could do is to
clearly define exactly which combinations of language constructs may
behave in an unexpected way, and document them up front in a prominent
place.

Otherwise, we risk turning off potential users -- I can just imagine a
newbie to D writing something like "File[] files;" and then wondering
why things don't work as expected, and then throwing in the towel and
say "what a lousy language, let me move on to another one".

And on that note, I'd like to say that my previous posts about
prohibiting structs with dtors as class members (if we were to move in
the direction of getting rid of class dtors altogether, which happily
isn't the case anymore) were primarily motivated by the desire to see
more of D obeying the principle of least surprise: two built-in language
constructs, structs with dtors and class members, when combined
together, *should* Just Work -- one expects that dtors will get called
with the struct goes out of scope, by the very definition of a dtor, so
one would expect they will still get cleaned up when they happen to be a
class member. The fact that they don't is a surprise, which then
requires some other way of warning the user that things aren't what they
might be expected to be. Maybe my proposed solutions suck, but the
underlying problem still needs to be addressed. The scope of the problem
is smaller, now that we're no longer killing off class dtors, but
nevertheless something needs to be done about it.

I think this is one area where D could use a lot of improvement. There
are currently a handful of glaring holes where built-in language
constructs interact with each other in unexpected or buggy ways.  While
it may feel like mole-whacking (because of combinatorial explosion as
you add features to the language), I think it's very important to
address, since otherwise it gives new users an impression (not
necessarily well-founded, but first impressions do matter) of sloppy
language design. The seams show through, and it's not very nice. One
example is the interaction of dtors with the GC. Another example is the
interaction of const/immutable with AA's. Another is the interaction of
@disabled with .init and other generic code. It seems that almost every
non-trivial use of these features is like navigating a minefield --
there are so many gotchas, unexpected behaviours, and implementation
bugs, that it's embarrassing. Other areas include shared, though I don't
have first-hand experience of that so I can't speak for it.

While proposing radical changes may be exhilarating, in the long run
that may do more harm than good. What these features need is some TLC
and detailed fine-tuning within the current, already-existing framework.

TL;DR: I'd like to see more attention paid to the details of how
language features interact with each other, and fixing those issues,
rather than inventing more radical new ideas that may or may not solve
the problem, and more likely than not will introduce new problems to add
to our already-long list of issues.


T

-- 
Amateurs built the Ark; professionals built the Titanic.