On Wednesday, 28 July 2021 at 08:40:47 UTC, claptrap wrote:

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.

On Wednesday, 28 July 2021 at 12:49:28 UTC, Paul Backus wrote:

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.

On Wednesday, 28 July 2021 at 16:57:41 UTC, Bruce Carneal wrote:

Do you have ideas on how to stop unsafe blocks accessing the variables from the surrounding scope? Is that even a goal for the DIP?

Do you have ideas on how to stop unsafe blocks accessing the variables from the surrounding scope? Is that even a goal for the DIP?

On Wednesday, 28 July 2021 at 17:25:18 UTC, claptrap wrote:

I'm not sure it necessarily is. Consider the following example (using the proposed @trusted-with-@system-blocks syntax):

/// Writes something into the provided buffer, e.g. filling the
/// buffer with random bytes
extern(C) void writeIntoCBuffer (int* ptr, size_t len) @system;


void writeIntoDBuffer (ref int[] buf) @trusted
{
    @system { writeIntoCBuffer(buf.ptr, buf.length); }
}

That seems like a reasonable use-case for a @trusted wrapper of an underlying @system function, but if the @system block was forbidden from accessing variables from the surrounding scope, it wouldn't be possible.

Does that make sense, or have I misunderstood what you had in mind?

On Wednesday, 28 July 2021 at 17:25:18 UTC, claptrap wrote:

I'm not sure it necessarily is. Consider the following example (using the proposed @trusted-with-@system-blocks syntax):

/// Writes something into the provided buffer, e.g. filling the
/// buffer with random bytes
extern(C) void writeIntoCBuffer (int* ptr, size_t len) @system;


void writeIntoDBuffer (ref int[] buf) @trusted
{
    @system { writeIntoCBuffer(buf.ptr, buf.length); }
}

That seems like a reasonable use-case for a @trusted wrapper of an underlying @system function, but if the @system block was forbidden from accessing variables from the surrounding scope, it wouldn't be possible.

Does that make sense, or have I misunderstood what you had in mind?

On Thursday, 29 July 2021 at 08:16:08 UTC, Joseph Rushton Wakeling wrote:

/// Writes something into the provided buffer, e.g. filling the
/// buffer with random bytes
extern(C) void writeIntoCBuffer (int* ptr, size_t len) @system;


void writeIntoDBuffer (ref int[] buf) @trusted
{
    @system { writeIntoCBuffer(buf.ptr, buf.length); }
}

Not exactly, obviously if they cant access variables from the surround scope they'd be useless. But i think the idea (not something i knew about until this thread) is to have a safe api between trusted and system. So there's controlled / restricted access. Otherwise if you have a system block inside a trusted function, the system code could just trash anything it wants from the enclosing scope, which makes any guarantees you have from the code being checked a bit pointless.

So it's not just about narrowing down the amount of code that is marked @system, but also the amount of state that it can access.

IIUC that was the original reason for limiting @safe/@trusted/@system to only apply on functions. So it forces you think about API between them. But I guess it didn't work out as expected.