@system blocks and safer @trusted (ST) functions

Bruce Carneal bcarneal at gmail.com
Wed Jul 28 16:57:41 UTC 2021


On Wednesday, 28 July 2021 at 12:49:28 UTC, Paul Backus wrote:
> On Wednesday, 28 July 2021 at 08:40:47 UTC, claptrap wrote:
>> If you're saying the proposed "system blocks inside trusted 
>> functions" provide no advantage over teh current "trusted 
>> lambdas inside safe functions" yes thats true. But I think the 
>> point is trusted functions get more checking. Even if you say 
>> well you can achieve the same by just using a trusted lambda 
>> inside a safe function its not the same once you consider what 
>> people actually do.
>>
>> If you have just one trusted function in your app, then 
>> switching to this new regime would automatically give you more 
>> checking.
>>
>> You have to take into account how people will actually behave, 
>> even if you can technically achieve the same thing with the 
>> current system.
>
> If I understand correctly, there are two problems being 
> diagnosed in this discussion (overall--not just in your post), 
> and two solutions being proposed:
>
> * __Problem #1:__ most uses of function-level `@trusted` are 
> mistakes, and allow too much code to go without automatic 
> checks.
>
> * __Proposed Solution #1:__ get rid of function-level 
> `@trusted` as it currently exists. Instead, automatic safety 
> checks will only be disabled in specially-marked blocks (like 
> in Rust). This will encourage programmers to disable automatic 
> checking only for the specific lines of code where it is 
> actually necessary, rather than for the entire function.
>
> * __Problem #2:__ `@trusted` lambdas make code harder to review 
> and maintain because they have implicit dependencies on the 
> surrounding `@safe` code.
>
> * __Proposed Solution #2:__ ban `@trusted` lambdas, and force 
> programmers to put their `@trusted` code into separate 
> functions, which communicate with `@safe` code explicitly via 
> arguments and return values. (See: [Walter's PR][1]).
>
> There is logic to both of these proposals, but their solutions 
> conflict: one pushes for less use of function-level `@trusted`, 
> the other for more use of it.
>
> [1]: https://github.com/dlang/dlang.org/pull/3077

I see this as two problems with a common solution, rather than a 
conflict.

Problem 1: @trusted lambdas within @safe functions are very 
convenient but tricky.

Problem 2: we want more practical @safety in the evolving dlang 
code base with as close to zero additional programming load as we 
can manage.

Rather than post some half-baked evolution of the original 
proposal sketch here, I'll wait til the back and forth with Joe 
converges.  The current candidates there are, in my view, both 
simpler and more powerful than anticipated in the forum 
discussion.  The biggest open question is how things should 
evolve to reduce/eliminate meta programming friction (thanks for 
the caution Steven).

Unless we unexpectedly find ourselves with a lot of time on our 
hands, ETA on the DIP is still the end of the year.



More information about the Digitalmars-d mailing list