@trusted attribute should be replaced with @trusted blocks

[Johannes Pfau]

Am Wed, 15 Jan 2020 19:06:11 +0100 schrieb ag0aep6g:

> 
> 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.
> 


I think it shouldn't be much of a problem, as there is a very nice 
transition path:

* Add @system block support
* Add -transition=systemBlocks which enforces @system blocks in trusted 
functions
* Users gradually add @system blocks to their trusted functions, until 
everything compiles with -transition=systemBlocks. If you did not add all 
blocks yet, your code will still compile fine without -
transisition=systemBlocks
* -transition=systemBlocks becomes default

> 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.


I don't really like this. It makes @trusted functions completely useless 
legacy cruft. And there's no longer any way to annotate a function as 
'this is 100% safe code', so then you'll have to check every safe 
function as thoroughly as trusted functions.


-- 
Johannes