On Sat, 15 Feb 2014 07:33:04 -0500, Jakob Ovrum <jakobov...@gmail.com>
wrote:
On Friday, 14 February 2014 at 15:56:16 UTC, Steven Schveighoffer wrote:
Classes are typically written with an expectation that the GC will
clean them up. I don't think you can just get rid of that expectation.
A class written without the assumption of the runtime is a very
different object, and I would be hesitant to name it 'class' in D.
I recommend not supporting classes, at least for now.
-Steve
This applies to the `new` operator, not classes in general. Classes
should be supported but not `new`.
New is not the issue. The expectation, when I write my class, that it will
be cleaned up by the GC, is the issue.
I remember this little nugget of paradox from the documentation of classes:
"This means that when the garbage collector calls a destructor for an
object of a class that has members that are references to garbage
collected objects, those references may no longer be valid. This means
that destructors cannot reference sub objects. This rule does not apply to
auto objects or objects deleted with the DeleteExpression, as the
destructor is not being run by the garbage collector, meaning all
references are valid."
So if you can write your class such that it will always require manual
deletion, it's OK to refer to other GC'd objects in the destructor.
Otherwise, it's not. Oh, and the runtime doesn't tell you when you're in
the GC :)
This leads us to the fun problem:
1. Without a GC, a destructor is REQUIRED to clean up owned resources that
were (likely) malloc'd.
2. With a GC, a destructor is REQUIRED to NOT clean up owned resources
that were GC'd.
How to write such a destructor?
But, besides that point: most classes are written expecting the GC to be
used. They might possibly not use the new expression internally (or any
other banned expressions by this new feature), and therefore compile.
However, the expectation when writing such a class is that the GC will
clean up after it. It's more the code that isn't there, than code that is
forbidden.
If we allowed classes, we would have to have an "opt-in" mechanism, so one
can indicate to the compiler that it can be used in this restricted mode
(yes, compiler, I handle manual destruction properly).
I think that the best and quickest approach at this time is to disallow
classes. They are not trivial. If we can figure out a clean way to add
them back, then they can be allowed later.
-Steve
