Am 16.06.2021 um 13:38 schrieb RazvanN:
> Currently, @trusted applies only to functions. This is most of the times a pain when you want trusted code blocks inside functions. Why not simplify it a bit by using trusted scope blocks?

Yes, please! There are 800 of these in vibe.d alone. There has also been an issue where the delegate workaround was erroneously flagged as a heap delegate, causing considerable GC memory load.

`@trusted` *should* probably not even be available for functions (of course it is not a desirable breaking change to disallow that now, though).

On 6/16/21 8:06 AM, jmh530 wrote:
> On Wednesday, 16 June 2021 at 11:38:54 UTC, RazvanN wrote:
>> [snip]
>>
>> ```d
>> void foo() @safe
>> {
>>     @trusted
>>     {
>>         int[100] a = void;
>>     }
>>     ...
>> }
>> ```
>>
>> [snip]
> 
> The documentation related to these @trusted blocks should emphasize that the block should be large enough to encompass enough information to verify the safety of what would normally require the function to be labelled @system. For instance, in your above example, just void initializing is @system, but if you fill `a` later outside the @trusted block later, then it is harder to verify that it is actually @safe.

You mean like it does now?

```d
void foo() @safe
{
   int[100] a = () @trusted {int[100] a = void; return a; }();
}
```

(in LDC, this compiles equivalent to Razvan's code above, not sure about DMD)

For @trusted blocks or inner @trusted functions, it's really difficult to say what parts are trusted and what parts are safe. See my [dconf online 2020 talk](http://dconf.org/2020/online/index.html#steven).

Right now, safe has 2 meanings, one is that code within it is safe, one is that code marked @safe is mechanically checked by the compiler. Only the mechanical checking is guaranteed, the semantic meaning that the code actually is safe is easily thwarted by inner trusted code.

This is the impetus behind [DIP1035](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1035.md).

But as long as we want code to do anything interesting, there is always going to be some trusted code, and the risks that come with it.

I would support @trusted blocks, as long as we can have @system variables (DIP1035) and variables declared inside a @trusted block were implicitly @system.

-Steve

On Wednesday, 16 June 2021 at 13:17:41 UTC, Steven Schveighoffer wrote:
> [snip]
>
> You mean like it does now?
> [snip]

See the code example I have above. My point isn't about @trusted per se, it's about best practices for using a @trusted code block.

In my opinion, your @trusted lambda example is a bad use of @trusted because you're not filling in the void initialized variable within @trusted code area. The person who is trying to manually verify that what is in the @trusted block is actually safe has to search for that outside the block.

On 6/16/21 9:09 AM, Sönke Ludwig wrote:
> Am 16.06.2021 um 13:38 schrieb RazvanN:
>> Currently, @trusted applies only to functions. This is most of the times a pain when you want trusted code blocks inside functions. Why not simplify it a bit by using trusted scope blocks?
> 
> Yes, please! There are 800 of these in vibe.d alone. There has also been an issue where the delegate workaround was erroneously flagged as a heap delegate, causing considerable GC memory load.
> 
> `@trusted` *should* probably not even be available for functions (of course it is not a desirable breaking change to disallow that now, though).

If I were to design it today:

- a @safe function could not call @trusted functions that gained implicit access to local data (i.e. inner functions, or non-static member functions from the same type).
- a @trusted function would be mechanically checked just like @safe, but could have @system blocks in them (where you could call @system functions, or do @system-like behaviors).

This at least puts the emphasis on where manual verification is required, but still has the compiler checking things I want it to check. Most times, I never want to write a fully marked @trusted function, because it's so easy to trust things you didn't intend to (like destructors).

-Steve

On 6/16/21 9:22 AM, jmh530 wrote:
> On Wednesday, 16 June 2021 at 13:17:41 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> You mean like it does now?
>> [snip]
> 
> See the code example I have above. My point isn't about @trusted per se, it's about best practices for using a @trusted code block.
> 
> In my opinion, your @trusted lambda example is a bad use of @trusted because you're not filling in the void initialized variable within @trusted code area. The person who is trying to manually verify that what is in the @trusted block is actually safe has to search for that outside the block.

Of course it's bad. But this is how code is written today, because @trusted is too blunt an instrument (I might want just void initialization of that one variable, but still want other @safety checks throughout the rest of the function).

My point (in a slightly snarky reply, apologies) is that we don't need a new @trusted block feature to have the documentation identify such pitfalls.

-Steve