Simplification of @trusted

[Steven Schveighoffer]

On 6/16/21 8:06 AM, jmh530 wrote:
> On Wednesday, 16 June 2021 at 11:38:54 UTC, RazvanN wrote:
>> [snip]
>>
>> ```d
>> void foo() @safe
>> {
>>     @trusted
>>     {
>>         int[100] a = void;
>>     }
>>     ...
>> }
>> ```
>>
>> [snip]
> 
> The documentation related to these @trusted blocks should emphasize that 
> the block should be large enough to encompass enough information to 
> verify the safety of what would normally require the function to be 
> labelled @system. For instance, in your above example, just void 
> initializing is @system, but if you fill `a` later outside the @trusted 
> block later, then it is harder to verify that it is actually @safe.

You mean like it does now?

```d
void foo() @safe
{
    int[100] a = () @trusted {int[100] a = void; return a; }();
}
```

(in LDC, this compiles equivalent to Razvan's code above, not sure about 
DMD)

For @trusted blocks or inner @trusted functions, it's really difficult 
to say what parts are trusted and what parts are safe. See my [dconf 
online 2020 talk](http://dconf.org/2020/online/index.html#steven).

Right now, safe has 2 meanings, one is that code within it is safe, one 
is that code marked @safe is mechanically checked by the compiler. Only 
the mechanical checking is guaranteed, the semantic meaning that the 
code actually is safe is easily thwarted by inner trusted code.

This is the impetus behind 
[DIP1035](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1035.md).

But as long as we want code to do anything interesting, there is always 
going to be some trusted code, and the risks that come with it.

I would support @trusted blocks, as long as we can have @system 
variables (DIP1035) and variables declared inside a @trusted block were 
implicitly @system.

-Steve