On 18/06/2021 1:54 AM, ag0aep6g wrote:
>> Ok, but it is not _realistic_ to think that D users will not write code that they think is _good enough_ for their purpose. Since there is no way to verify that they  adhere to idealistic principles, it won't happen.
> 
> I think there's almost a consensus that @trusted isn't quite good enough, exactly because no one can be bothered to use it as intended. That's why the incremental improvements mentioned above are being worked on. I don't think anyone is working on redesigning (or reinterpreting) the whole thing from the ground up. And I would expect strong push-back from Walter if someone tried.

What might be a good thing to have is make the compiler able to produce an audit report for @trusted code. Along with a list of all @trusted symbols in source code (not generated).

You can diff the list to see what symbols are added, and ensure somebody audits it at PR time with the help of the CI.

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

On Thursday, 17 June 2021 at 14:30:58 UTC, Steven Schveighoffer wrote:
> [snip]
> 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.
>

I think I've suggested before a @safe-strict, or something like that, that is the same as @safe but only allows calling @safe-strict functions (@safe/@trusted/@system functions can all call a @safe-strict function). The idea would be that those shouldn't need to be reviewed for the issues that @safe attempts to address.

You could then have @safe-strict blocks to complement the @system blocks you discussed previously (I've come along to the idea that @trusted blocks is a bad idea, you really just need these two). The idea would be that the @safe-strict blocks within a @safe/@trusted/@system function would be mechanically checked and since they do not call any @safe/@trusted/@system not need to be reviewed. Of course, one might argue that this results in mixing up @system code with @safe-strict code. However, it also helps separate out the safer parts of unsafe code. For instance, this approach means that you have a backwards compatible way to have the code in a trusted function that is not in a system block be checked manually (see below, @system block would be optional).

```d
@trusted void foo()
{
    @safe-strict {
        //mechanically checked code that can't call any @safe/@trusted/@system functions
    }
    //system code
}
```

On 2021-06-16 17:22, Walter Bright wrote:
> On 6/16/2021 6:09 AM, Sönke Ludwig wrote:
>> There are 800 of these in vibe.d alone.
> 
> That is concerning. But it isn't necessarily cause for redesigning @trusted. For example, I removed (in aggregate) a great deal of unsafe allocation code from the backend simply by moving all that code into one resizable array abstraction.
> 
> Piece by piece, I've been removing the unsafe code from the backend. There really should be very, very little of it.
> 
> 
>> There has also been an issue where the delegate workaround was erroneously flagged as a heap delegate, causing considerable GC memory load.
> 
> I can't think of a case where:
> 
> () @trusted { ... }();
> 
> would make it a heap delegate. Such cases should be in bugzilla.
> 
> 
>> `@trusted` *should* probably not even be available for functions (of course it is not a desirable breaking change to disallow that now, though).
> 
> The idea is to encourage programmers to think about organizing code so that there are clear separations between safe and system code. Interleaving the two on a line-by-line basis defeats the purpose.

I think the whole discussion should be redirected toward simplifying `pure` instead.

* There are many legitimate reasons to want impure code act as pure.
* There is no easy recourse as there is for @trusted. All approaches are crazily convoluted.

On Thu, Jun 17, 2021 at 11:49:50AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> I think the whole discussion should be redirected toward simplifying `pure` instead.
> 
> * There are many legitimate reasons to want impure code act as pure. * There is no easy recourse as there is for @trusted. All approaches are crazily convoluted.

What are the actual advantages of code being marked pure?  I'm all for generalizing pure, but does it bring enough actual benefits to be worth the effort?

I'm not talking about theoretical benefits, but actual benefits that the compiler can actually make use of to emit better code.  I used to be a big fan of pure, but in practice I've found that it doesn't make *that* much of a difference in terms of codegen.  Maybe I'm missing something, in which case I'd love to be enlightened.


T

-- 
Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them. -- Unknown

On Thursday, 17 June 2021 at 16:21:53 UTC, Paul Backus wrote:
> On Thursday, 17 June 2021 at 14:30:58 UTC, Steven Schveighoffer wrote:
>> [...]
>
> Consider the following example:
>
> ```d
> size_t favoriteNumber() @safe { return 42; }
>
> int favoriteElement(ref int[50] array) @trusted
> {
>     // This is memory safe because we know favoriteNumber returns 42
>     return array.ptr[favoriteNumber()];
> }
> ```
>
> `favoriteElement` has a safe interface. There is no argument you can pass to it from `@safe` code that can possibly result in memory corruption.
>
> However, if you change `favoriteNumber` to return something different (for example, 69), this may no longer be the case. So changes to `favoriteNumber`--a `@safe` function with no `@trusted` escapes--must still be manually reviewed to ensure that memory safety is maintained.
>
> There is no language change you can make (short of removing `@trusted` entirely) that will prevent this situation from arising.

Apart from reviewers asking the author of favoriteElement  to assert that the index is appropriate ...

That's exactly the reason behind a review of trusted function, you need to check only it's source code.