destroy and @safe

[H. S. Teoh]

On Tue, Jun 21, 2022 at 04:47:44PM +0000, Antonio via Digitalmars-d-learn wrote:
> On Tuesday, 21 June 2022 at 16:20:32 UTC, Antonio wrote:
> 
> > 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)
[...]

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.


T

-- 
This is not a sentence.