On Friday, 26 May 2017 at 17:48:24 UTC, Stanislav Blinov wrote:
I'm sorry, I ment explicitly. I hope it is not possible.
It is very possible, and it should be possible, otherwise we
couldn't even think about deterministic destruction.
Hm, you've said it is decision of GC (see bellow), so how can it
be deterministic?
Another side, clearly demonstrated by my second post, is that
non-deterministic destruction cannot be @safe, period.
Because when GC collects and calls destructors, it calls all
of them, regardless of their @safe status, even when the
collection is triggered inside a @safe function.
Doesn't that mean if compiler can't call inherited destructor
despite of GC it must be error?
1) Destructors are not "inherited" in D. Each derived class has
it's own independent destructor. That's why they don't inherit
any attributes either.
2) Compiler doesn't call destructors for classes. It is done
either manually (by calling destroy()) or by the GC. Look at
the example in the second post: I'm in @safe function
(important()), I need some memory. I ask for it, the GC decides
to do a collection before giving me memory. And during that
collection it calls a @system destructor.
So the language and runtime are effectively in disagreement:
language says "no @system calls in @safe context", runtime says
"whatever, I need to call those destructors".
Your example is very interesting and it derives some questions.
First, why 'oblivious' function does not free Malicious object
(no matter GC or not GC). What if 'important' function needs some
"external an not safe" resource used by 'oblivious'? Is it all
about @safe that stops allowing it? If so, @safe is really
important feature in Dlang. Second, same as first, it looks like
I got it.
