https://issues.dlang.org/show_bug.cgi?id=22507
Issue ID: 22507 Summary: Struct destructors must enjoy special status with regard to @safe/@trusted/@system Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: and...@erdani.com >From https://forum.dlang.org/post/vjptvzqpaobvadnof...@forum.dlang.org: 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". --