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".
--
