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