The problem:

"use" can't be @safe because it contains a call to "destroy".

I'm using explicitly destroy!false(obj) for a "deterministic" resources release.

I replicate the c# "using" pattern, or the python "with" pattern with my own "use" template supposing object are RAII

i.e.:

Item[] items = query("...").use( (Answer a) =>
   a.rangify.map!(rowToItem).array()
);

The problem:

"use" can't be @safe because it contains a call to "destroy".

For better understanding of the idea, I include the "use" template code

R use(R, T)(T obj, R delegate(T) fT)
{
   scope (exit)
     destroy!false(obj);

   return fT(obj);
}

What's the way to ensure @safe using destroy? (if possible)

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.

.... You delegate doesn't seem to be marked @safe as well.

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"

On Tuesday, 21 June 2022 at 15:14:43 UTC, Steven Schveighoffer wrote:

Thanks a lot Steve,

I didn't found a way (or example) to specify the delegate must be @safe until I have found vibe.d.db.postgress implementation (that you maintain :-)

On Tue, Jun 21, 2022 at 04:47:44PM +0000, Antonio via Digitalmars-d-learn wrote:

IMO, that's a wrong design on the part of the library. The library ought
to cater to user code, not the other way round; it should take advantage
of @safe user code where it can, but should not force the library user
to use @safe. The library code itself should be @safe, but it ought to
be callable from @system code unless there's a good reason it can't be.

I can foresee, though, a potential issue with delegates, since once you
mark them @safe, it forces user code to be @safe. If you don't mark them
and they default to @system, then the library code that calls those
delegates would also have to be @system.

This is why I've proposed in the past that @safe functions should be
allowed to call @system delegates that they receive as arguments. The
reasoning goes like this: if the delegate was in fact @safe (i.e., it's
a @safe delegate passed to a @system parameter -- @safe is covariant
with @system), then there is no problem. If the delegate was @system,
then the caller can only have been called from @system somewhere up the
call stack (@safe code can't create @system delegates), so we're also
OK: if the caller was @system, then we guarantee nothing anyway.
However, Walter didn't seem convinced by this proposal.