On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer
wrote:
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
Note that the same applies to classes with ARC (or other
reference counting mechanism).
