On Tuesday, 21 June 2022 at 15:13:36 UTC, Paul Backus wrote:
If the destructor is `@system`, then the only way to call
`destroy` in `@safe` code is to (1) determine the conditions
necessary to call the destructor without violating memory
safety, (2) ensure that those conditions are met (using compile
time and/or runtime checks), and (3) wrap the call to `destroy`
in a `@trusted` function.
Since step (1) depends on the specific details of the
destructor you want to call, I can't give any more specific
advice unless you show a complete example that includes the
destructor.
Thanks Paul.
The problem appears when destroying a dpq2 query result object
(not @safe). I supose I can accept postgres PGClean(result) is
safe "enought".
My code starts to be a @safe/@trusted mess (because external
libraries). The only solution I have is to "wrap" them or to
trust all code by default (I'm using vibe.d that forces @safe
code)
Only as a comment: I can remember now when dart/flutter
incorporated "sound null safety" and most of the third-party
libraries where ported by authors... everybody assumed this will
be the way of. D @safe "optional" adoption is a problem
As a personal advice, I would change the scoring system of the
packages to penalize when they are not "safe"
