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