How does rt_finalized function work exactly? (Fixing bugs regarding Destroy).

12345swordy alexanderheistermann at gmail.com
Fri Jan 19 19:48:07 UTC 2018


On Friday, 19 January 2018 at 18:22:33 UTC, Steven Schveighoffer 
wrote:
> On 1/19/18 10:56 AM, 12345swordy wrote:
>> I can't find any documentation nor can I find any information 
>> regarding it's implementation. I am asking this, as I focusing 
>> on fixing bugs that destroy currently has, most noticeably 
>> bugs regarding attributes. I am not sure that this requires a 
>> DIP in order to fix this.
>> 
>> https://issues.dlang.org/show_bug.cgi?id=17297
>> https://issues.dlang.org/show_bug.cgi?id=15246
>
> So there has been very little definition around how destructors 
> use and inherit attributes. Most of this is because destructors 
> are generally called from the GC, where it doesn't matter at 
> all what the attributes are.
>
> I think before you can fix such things, we need a clear model 
> of how the destructors are called, and what is inherited and 
> what is overridden in base classes. Then we can think about how 
> to fix the situation.
>
> Note that:
>
> a. The GC must have a *runtime* definition of how to call the 
> destructors. And we need to statically disallow the GC from 
> calling destructors it shouldn't be allowed to call (if such 
> cases exist).
> b. Object.~this can't be a decider of what the attributes 
> should be, as this prevents adding any additional attributes.
> c. There is a push recently (by Andrei and Lucia and others) to 
> remove some of the "magic" calls from the compiler, and replace 
> them with templates, so we can have more library control over 
> what happens (and more comiple-time introspection). This should 
> help quite a bit in the implementation of such things. But we 
> definitely are limited by the virtual-ness of Objects, and the 
> opaqueness of the GC.
>
> -Steve

I see, this does look like it needs a DIP in order to fix this. 
How the progress of the calls being replaced by templates by 
Andrei and company?


More information about the Digitalmars-d mailing list