Simplification of @trusted

jmh530 john.michael.hall at gmail.com
Wed Jun 16 16:40:42 UTC 2021


On Wednesday, 16 June 2021 at 13:25:09 UTC, Steven Schveighoffer 
wrote:
> [snip]
>
> If I were to design it today:
>
> - a @safe function could not call @trusted functions that 
> gained implicit access to local data (i.e. inner functions, or 
> non-static member functions from the same type).
> - a @trusted function would be mechanically checked just like 
> @safe, but could have @system blocks in them (where you could 
> call @system functions, or do @system-like behaviors).
>
> This at least puts the emphasis on where manual verification is 
> required, but still has the compiler checking things I want it 
> to check. Most times, I never want to write a fully marked 
> @trusted function, because it's so easy to trust things you 
> didn't intend to (like destructors).
>
> -Steve


I see what you're saying. I agree the @trusted function with the 
@system blocks within them is better than @safe functions with 
@trusted blocks, all else equal. The downside is that the only 
way to do it without breaking code is to introduce an alternative 
to @trusted since @safe checking for @trusted would break code.

However, consider if you can have @safe/@trusted/@system blocks 
(such that a @safe block does manual checking). In that case, you 
could have something like below
@trusted
{
     @safe
     {
         // some safe code that you want manually checked
         //...
         @trusted
         {
             @system
             {
                 // some @system code
             }
             // some @trusted code using the @system code
         }
     }
     // some other trusted code
}


More information about the Digitalmars-d mailing list