Bounty for -minimal compiler flag

Steven Schveighoffer schveiguy at yahoo.com
Sat Feb 15 18:57:24 PST 2014


On Sat, 15 Feb 2014 07:33:04 -0500, Jakob Ovrum <jakobovrum at 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


More information about the Digitalmars-d-announce mailing list