Simplification of @trusted

[GrimMaple]

On Wednesday, 16 June 2021 at 21:22:32 UTC, Walter Bright wrote:
> On 6/16/2021 6:09 AM, Sönke Ludwig wrote:
>> There are 800 of these in vibe.d alone.
>
> That is concerning. But it isn't necessarily cause for 
> redesigning @trusted. For example, I removed (in aggregate) a 
> great deal of unsafe allocation code from the backend simply by 
> moving all that code into one resizable array abstraction.
>
> Piece by piece, I've been removing the unsafe code from the 
> backend. There really should be very, very little of it.
>
>
>> There has also been an issue where the delegate workaround was 
>> erroneously flagged as a heap delegate, causing considerable 
>> GC memory load.
>
> I can't think of a case where:
>
> () @trusted { ... }();
>
> would make it a heap delegate. Such cases should be in bugzilla.
>
>
>> `@trusted` *should* probably not even be available for 
>> functions (of course it is not a desirable breaking change to 
>> disallow that now, though).
>
> The idea is to encourage programmers to think about organizing 
> code so that there are clear separations between safe and 
> system code. Interleaving the two on a line-by-line basis 
> defeats the purpose.

But what about allowing @safe blocks (increasing the safety 
level) to encourage safety checks in system code? I made an 
exmaple above:

```d
void foo() @trusted
{
     int[100] a = void;
     @safe
     {
         // Code with safety checks
     }
}
```

And having @trusted/@system blocks inside @safe functions would 
be disallowed by compiler.