Simplification of @trusted

[Steven Schveighoffer]

On 6/16/21 9:07 PM, Paul Backus wrote:
> 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.

The goal is to guarantee that *as long as* your @trusted functions and 
blocks have a @safe interface, then @safe code does not need to be 
checked. When I say "not require review" I mean "I have checked all the 
@trusted code, and it has a sound @safe interface, so all @safe code 
that may call it have no need for review." We will never have a marking 
that is language-guaranteed to not require review.

To put it another way, as long as you aren't using @trusted escapes that 
leak implementation details, your @safe code shouldn't need a review. 
The problem is that trusted lambdas are not only the norm, it's actually 
required, due to template inference.

Right now, a @safe function can only be "assumed safe" as long as there 
are no @trusted blocks in it. Once there is one trusted block, then you 
have to review the whole function. The same thing goes for data 
invariants (though that spreads to the whole module instead).

Not having to review code for memory safety is supposed to be the major 
point of @safe.

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

A truly "correct" @trusted function should defensively be callable and 
provide appropriate return data for any possible @safe interface. A 
trusted escape accepts as a parameter "everything" from the outer 
function, and returns "everything". Which means the @safe function can 
add or subtract *at will* any parameters of any type or return values 
that it wants. This just isn't reviewable separately.

We might as well call a spade a spade.

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

If D had a hard requirement (enforced by having undefined behavior 
threats) that @trusted functions should always have a safe interface, 
then you could say that @safe code needs no review. Limiting what a 
@trusted function can do helps the ability to verify that the interface 
is indeed safe.

This is all kind of moot though, I don't see any change to the safe 
regime happening. The best we might get is DIP1035.

-Steve