Bug 17867 – @trusted destructor not callable from @safe function
Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2017-09-30T17:18:20Z
Last change time
2018-04-23T00:17:43Z
Assigned to
No Owner
Creator
Andrei Alexandrescu
Comments
Comment #0 by andrei — 2017-09-30T17:18:20Z
Consider:
struct S
{
@system ~this() {}
}
struct T
{
S member;
@trusted ~this() {}
}
@safe void main()
{
T obj;
}
This code should work because although the member's destructor is @system, the object containing it makes it safe. The code fails with:
Error: @safe function 'D main' cannot call @system destructor 'test.T.~this'
Couldn't find a convenient workaround.
Comment #1 by schveiguy — 2017-10-02T12:58:35Z
It should work, IMO.
Note that the way this looks internally is kind of bizarre. The actual ~this() function is separate from the one that calls the member's dtor. So I can see how it would not glue together right under the hood.
In other words, the compiler generates a function that does this:
realdtor()
{
~this();
member.~this();
}
And I don't know if there's a way to annotate that one.
Comment #2 by simen.kjaras — 2018-02-07T12:51:14Z
*** This issue has been marked as a duplicate of issue 15246 ***
Comment #3 by alexanderheistermann — 2018-04-22T23:29:27Z
No, this is NOT a duplicate, as the example he had given involved structs not classes. The is no destructor inheritance when it comes to structs.
Comment #4 by simen.kjaras — 2018-04-23T00:17:43Z
The cause is the same - no inheritance is necessary. Allow me to demonstrate:
struct S1 {
int value;
~this() {
value = 17;
}
}
struct S2 {
S1 a;
~this() { }
}
unittest {
S2 s;
s.__dtor();
// Would have been 17 if S1's destructor was run.
assert(s.a.value == 0);
// Note the existence of "__xdtor", which is a separate
// method that calls member destructors.
pragma(msg, __traits(allMembers, S2));
s.__xdtor();
assert(s.a.value == 17);
}
This clearly shows that S2's destructor does *not* call S1's destructor, and thus that the code is valid. (it's validity may be undesired, but it's still valid)
The only value of having this issue open in addition to issue 15246 would be if 15246 is inadequately described. If that's the case, 15246 should be amended, not this issue.
*** This issue has been marked as a duplicate of issue 15246 ***