Simplification of @trusted

[Paul Backus]

On Thursday, 17 June 2021 at 00:34:12 UTC, Steven Schveighoffer 
wrote:
> On 6/16/21 5:32 PM, Paul Backus wrote:
>> On Wednesday, 16 June 2021 at 21:26:08 UTC, Bruce Carneal 
>> wrote:
>>> I like the notion that others have mentioned of @safe 
>>> checking by default within @trusted code (which would require 
>>> @system blocks to disable checking).  Perhaps we could adopt 
>>> an opt-in strategy where such @safe checking is triggered by 
>>> the presence of an @system block.
>> 
>> Under this proposal, @system lambdas/blocks within @trusted 
>> code would have the exact same semantics as @trusted 
>> blocks/lambdas within @safe code currently do. It's pure 
>> bikeshedding.
>
> Yes, and that leaves @safe code to actually not require manual 
> checking, as opposed to today, where any @safe code with 
> @trusted blocks today requires manual checking of all the @safe 
> code (I agree just changing trusted/system code this way, and 
> doing nothing with @safe would be bikeshedding).
>
> In reality, @safe code should be a function of its inputs, and 
> what is considered a safe input. With @trusted lambdas, the 
> inputs are "everything".

It's impossible to guarantee, at the language level, that @safe 
code can never require manual review. The programmer is allowed 
to use any and all knowledge at their disposal to verify the 
memory safety of @trusted (or in your proposal, @system-block) 
code, including knowledge about @safe code.

You might say, "the only thing a @trusted function can possibly 
know about a @safe function is its signature, so that doesn't 
matter," but that's not quite true. If the @trusted function and 
the @safe function are in the same module, the @trusted function 
can (in principle) rely on the inner workings of the safe 
function without invalidating its proof of memory safety, since 
the programmer knows that any given version of the @trusted 
function will only ever call the corresponding version of the 
@safe function.

Of course, such a @trusted function should never pass code 
review. But the fact that it can exist in principle means that 
you cannot truly rely on @safe to mean "no manual checking 
required", even if @trusted lambdas and nested functions are 
forbidden.