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.