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.


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.


Note that the same applies to classes with ARC (or other reference counting mechanism).

Reply via email to