@trusted attribute should be replaced with @trusted blocks

[ag0aep6g]

On Thursday, 16 January 2020 at 15:30:45 UTC, Steven 
Schveighoffer wrote:
[...]
>> But as Steven says, it can be done when we use @trusted blocks 
>> instead of @system blocks and @safe instead of @trusted on the 
>> function. I.e.:
>> 
>>      @safe fun ()
>>      {
>>          // lines that the compiler accepts as @safe go here
>>          @trusted {
>>              // these lines are allowed to use @system code
>>          }
>>          // only @safe lines here again
>>      }
>> 
>> It weakens the meaning of @safe somewhat, but it's often 
>> treated that way already. There's clearly a need.
>
> @safe code is tremendously hampered without @trusted. You could 
> only do things like simple math. As soon as you start needing 
> things like memory allocation, or i/o, you need escapes. That 
> is the reality we have.

Three ways to design @safe/@trusted:

1) @safe cannot call @trusted. I agree that this would be 
virtually useless.
2) @safe can call @trusted. @trusted functions must be 
self-contained safe. This is how @trusted is currently meant to 
work.
3) @safe code can contain @trusted parts (blocks/lambdas). Those 
@trusted parts may rely on the surrounding @safe code for safety. 
The @safe parts are effectively in a third state: Mechanical 
checks are performed, but manual checks are still needed to 
verify the interaction with the @trusted parts.

Whenever we disagree, it's about #2 vs #3. #1 is not on the 
table, as far as I'm concerned.

#3 is how you're treating @trusted in practice. I don't think 
doing that is strictly speaking valid today. But if we do get 
@trusted blocks, that's an opportunity to make it valid. I.e., 
we'd be going from #2 to #3. And that's what I meant by 
"[weakening] the meaning of @safe".

In contrast, with @system blocks (in @trusted functions) we could 
make #2 more practical.

To reiterate, I'm ok with both @system blocks and @trusted 
blocks. I'd even be ok with changing the spec to #3 without 
getting any kind of block syntax. But that would be harder to 
formalize, and there's no point in doing it if we want to 
transition to block syntax anyway.

The only thing I oppose is working with #3 while keeping the 
officially documented rules at #2. Something should be done about 
that one way or the other. And if block syntax gets introduced, 
then that's the time to strike.