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.
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.
*** This issue has been marked as a duplicate of issue 15246 ***
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.
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 ***