On Wednesday, 16 June 2021 at 11:38:54 UTC, RazvanN wrote:

void foo() @safe
{
    () @trusted { ... }();
}

void foo() @safe
{
    @trusted
    {
       ....
    }
}

YES PLEASE!
This was suggested since years meanwhile!
(and by the way: the use of @trusted at functions should be deprecated - a function should either be @save or @system, nothing in between. Only @trusted blocks should be allowed)

On Wednesday, 16 June 2021 at 11:38:54 UTC, RazvanN wrote:

Yes.

On Wednesday, 16 June 2021 at 11:38:54 UTC, RazvanN wrote:

void foo() @safe
{
    () @trusted { ... }();
}

void foo() @safe
{
    @trusted
    {
       ....
    }
}

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

I don't like that this allows implicitly lowering the safety level of any given function. As per example, the foo() function isn't @safe anymore, but @trusted. Which in turn should be reflected in the function signature. If this function is marked as @safe, I expect it to be @safe and not perform any shady stuff inside it. To me this really looks like foo() should be @trusted instead.

What I like more, is permitting to temporarily increase the safety level by using eg @safe blocks inside a @trusted function. For example

void foo() @trusted
{
    int[100] a = void;
    @safe
    {
        // Code with safety checks
    }
}

Overall, if something like this is implemented, it should support all safety levels for blocks, including @safe and @system, for consistency purposes

On Wednesday, 16 June 2021 at 14:57:19 UTC, GrimMaple wrote:

void foo() @trusted
{
    int[100] a = void;
    @safe
    {
        // Code with safety checks
    }
}

I don't think that this is a good alternative. The normalcy we are striving for is to have as much code as possible @safe and as little as possible trusted. From that perspective it makes much more sense to annotate the entire function as @safe and have minor sections as being trusted.

I don't really see the point in having @safe/trusted blocks inside of @system functions or @system/trusted blocks inside @safe functions. As for trusted functions, although I like the idea of deprecating them, there are cases of functions that are a few lines of code long (or even one liners) that do some unsafe operations that can be trusted; in this situation it's much easier to annotate the function as trusted. However, outside of such scenarios (for big functions), annotating functions as trusted is bad practice.

On Wednesday, 16 June 2021 at 14:57:19 UTC, GrimMaple wrote:

There is no difference (from the caller's point of view) between the "safety level" of a @safe function and a @trusted function. Both are memory-safe. The only difference is that the @safe function has its safety checked automatically, by the compiler, and the @trusted function has its safety checked manually, by the programmer.

"But surely," you will object, "automatic checking is more reliable than manual checking, and therefore the @safe function is 'safer' than the @trusted one." Unfortunately, the conclusion does not follow from the premise: a @safe function is allowed to call any number of @trusted functions internally, so it is entirely possible that both functions rely on manual checking for their memory safety. You cannot tell just from looking at the signatures.

On Wednesday, 16 June 2021 at 15:58:23 UTC, RazvanN wrote:

void foo() @trusted
{
    int[100] a = void;
    @safe
    {
        // Code with safety checks
    }
}

With my approach, you can still cover as many code @safe as you want without lying to the end user about the function safety. IMHO, if you perform @trusted operations in a @safe function, the function cannot be called @safe .

The point is enabling @safe checks on parts of @system/@trusted code, that otherwise would require weird solutions. Or, if you prefer, to be consistent over the lang. I think it is more predictable to the user, that if you can mark a block @trusted, it can be marked @safe or @system as well

On Wednesday, 16 June 2021 at 16:17:28 UTC, GrimMaple wrote:

But this is not true. As Paul Backus pointed out, you can still have
a @safe function that calls trusted functions. Your argument seems
to imply that @safe should never interact with @trusted code, which
to be honest will make it unusable.

I understand, but my point is that if you have a @system function it is kind
of useless to have @safe portions of it, you still cannot call it from @safe code.
It makes much more sense to have a @safe function with small trusted blocks.