Bug 22507 – Struct destructors must enjoy special status with regard to @safe/@trusted/@system
Status
RESOLVED
Resolution
DUPLICATE
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2021-11-12T16:43:32Z
Last change time
2021-11-12T16:51:21Z
Assigned to
No Owner
Creator
Andrei Alexandrescu
Comments
Comment #0 by andrei — 2021-11-12T16:43:32Z
From https://forum.dlang.org/post/[email protected]:
In order to create an automatic object of type T in a safe function, T's destructor must be safe or trusted.
Currently the destructor is embodied by the __dtor member function, i.e. the attributes on the destructor's declaration are identical to those on the generated __dtor member function.
Some types need to define a destructor that does unsafe things, mainly deallocating memory that is carefully confined within the object.
This creates the following conundrum:
1. If such types make the destructor @trusted, it means safe code is also free to call __dtor() manually. Subsequent use of such objects is liable to break safetu.
2. If such types choose to make the destructor @system, it means safe code cannot create objects of those types at all.
At first blush, there needs to be a way to tell the compiler "destructor is to be trusted but only when called implicitly".
Comment #1 by dkorpel — 2021-11-12T16:51:21Z
*** This issue has been marked as a duplicate of issue 21981 ***