Am 30.04.2014 22:21, schrieb Andrei Alexandrescu:
Walter and I have had a long chat in which we figured our current
offering of abstractions could be improved. Here are some thoughts.
There's a lot of work ahead of us on that and I wanted to make sure
we're getting full community buy-in and backup.
First off, we're considering eliminating destructor calls from within
the GC entirely. It makes for a faster and better GC, but the real
reason here is that destructors are philosophically bankrupt in a GC
environment. I think there's no need to argue that in this community.
The GC never guarantees calling destructors even today, so this decision
would be just a point in the definition space (albeit an extreme one).
That means classes that need cleanup (either directly or by having
fields that are structs with destructors) would need to garner that by
other means, such as reference counting or manual. We're considering
deprecating ~this() for classes in the future.
Also, we're considering a revamp of built-in slices, as follows. Slices
of types without destructors stay as they are.
Slices T[] of structs with destructors shall be silently lowered into
RCSlice!T, defined inside object.d. That type would occupy THREE words,
one of which being a pointer to a reference count. That type would
redefine all slice primitives to update the reference count accordingly.
RCSlice!T will not convert implicitly to void[]. Explicit cast(void[])
will be allowed, and will ignore the reference count (so if a void[]
extracted from a T[] via a cast outlives all slices, dangling pointers
will ensue).
I foresee any number of theoretical and practical issues with this
approach. Let's discuss some of them here.
Thanks,
Andrei
Honestly, that sounds like the entierly wrong apporach to me. Your
approaching the problem in this way:
"We can not implement a propper GC in D because the language design
prevents us from doing so. So lets remove destructors to migate the
issue of false pointers."
While the approach should be.
"The language does not allow to implement a propper GC (anything else
then dirty mark & sweep), what needs to be changed to allow a
implementation of a more sophisticated GC."
Also let me tell you that at work we have a large C# codebase which
heavily relies on resource management. So basically every class in there
inherits from C#'s IDisposable interface which is used to manually call
the finalizer on the class (but the C# GC will also call that
finalizer!). Basically the entire codebase feels like manual memory
management. You have to think about manually destroying every class and
the entire advantage of having a GC, e.g. not having to think about
memory management and thus beeing more productive, vanished. It really
feels like writing C++ with C# syntax. Do we really want that for D?
And what if I want unsafe slices of structs with destructors, for
performance? Maybe I perfectly know that the memory behind the slice
will outlive the slice, and I don't want the overhead of all the
reference counthing behind it?
If you actually deprecate ~this, there would be two options for me.
1) Migrate my entire codebase to some user defiend finalizer function
(which doesn't have compiler support), which would be a lot of work.
2) Quit D. (which is becomeing more and more an option when reading the
recent news group discussions.)
--
Kind Regards
Benjamin Thaut
