destroy and @safe

[Steven Schveighoffer]

On 6/21/22 1:17 PM, H. S. Teoh wrote:
> 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.

```d
void foo(void delegate() @system dg) @safe {
    int *bar;
    @system void corrupt() { bar = cast(int *)0xdeadbeef;}
    dg = &corrupt;
    // can I call dg now?
}
```

-Steve