Bounty for -minimal compiler flag

[Denis Koroskin]

On Sunday, 16 February 2014 at 02:57:25 UTC, Steven Schveighoffer 
wrote:
> 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

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