@trusted attribute should be replaced with @trusted blocks

Johannes Pfau nospam at example.com
Wed Jan 15 18:38:25 UTC 2020

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


More information about the Digitalmars-d mailing list