@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