@trusted attribute should be replaced with @trusted blocks

Dominikus Dittes Scherkl dominikus at scherkl.de
Thu Jan 16 15:10:04 UTC 2020


On Wednesday, 15 January 2020 at 18:38:25 UTC, Johannes Pfau 
wrote:
> 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.

Oh, I hate that discussion.
@trusted functions were useless from the start. They are just the 
same as @safe from a caller perspective. And @trusted blocks are 
nothing new either, only the syntax is more ugly because 
anonymous lambdas are used to simulate them:

  () @trusted {
      // @system stuff here
  }()

And the argument that @trusted functions could better be found 
and that that would increase the safety is invalid. @trusted 
blocks can be searched just as good, and any function containing 
them still need to be treated with caution.


More information about the Digitalmars-d mailing list