@trusted attribute should be replaced with @trusted blocks

[ag0aep6g]

On 15.01.20 17:54, Joseph Rushton Wakeling wrote:
> On Wednesday, 15 January 2020 at 14:30:02 UTC, Ogi wrote:
[...]
>> @safe fun() {
>>     //safe code here
>>     @trusted {
>>         //those few lines that require manual checking
>>     }
>>     //we are safe again
>> }
[...]
> So here's the problem with this approach (which was mentioned by several 
> people in the discussion): the actual safety of a function like this is 
> usually down to the combination of the lines that (in your example) are 
> both inside and outside the @trusted block.

Yup. But a proposal could specify that that's the intended meaning for 
an @safe function that contains @trusted blocks. Whereas it's more of a 
cheat when we use @trusted nested functions like that.

[...]
> So, a better approach would be for the function to be marked up like this:
> 
> @trusted fun ()    // alerts the outside user
> {
>      // lines that on their own are provably safe go here
>      @system {
>          // these lines are allowed to use @system code
>      }
>      // only provably safe lines here again
> }
> 
> ... and the compiler's behaviour would be to explicitly verify standard 
> @safe rules for all the lines inside the @trusted function _except_ the 
> ones inside a @system { ... } block.
> 
> Cf. Steven Schveighoffer's remarks here: 
> https://forum.dlang.org/post/qv7t8b$2h2t$1@digitalmars.com
> 
> This way the function signature gives a clear indicator to the user 
> which functions are provably @safe, and which are safe only on the 
> assumption that the developer has done their job properly.

I don't think that's what Steven had in mind. In that world, @safe would 
be very, very limited, because it couldn't be allowed to call @trusted 
functions. That means @safe would only apply to trivial functions, and 
@trusted would assume the role that @safe has today. But you'd have to 
wrap every call from an @trusted to another @trusted function in an 
@system block. It wouldn't be practical.

The real purpose of @trusted in that example is to allow the @system 
block in the body, and to signal to reviewers and maintainers that the 
whole function is unsafe despite the mechanical checks that are done on 
most of the lines. To a user, @trusted functions would still be the same 
as @safe ones.

Unfortunately, adding the mechanical checks of @safe to @trusted would 
mean breaking all @trusted code that exists. So implementing that scheme 
seems unrealistic.

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.