On Sunday, 25 July 2021 at 12:05:10 UTC, Steven Schveighoffer wrote:

Yes, I agree.
First I was skeptical about this DIP, but that I think is the important advantage above @trusted blocks. So I would support this DIP.

On Sunday, 25 July 2021 at 23:50:12 UTC, Paul Backus wrote:

You could probably come up with an example bug that wouldn't be caught by any system you can think of as long as you have an @system escape hatch. It doesnt really prove anything imo.

On Sunday, 25 July 2021 at 17:47:40 UTC, Paul Backus wrote:

@system {
   return array.ptr[favoriteNumber()];
}

No, it's not. You use something that is not a literal, so it may change.
Even for a constant this should be checked for each new compile.
I would do that even if it actually were a literal, but here we have a function call!
The definition of the called function may be far away. How would this ever pass a review?
The only way to make this memory safe, is to actually test it:

@system {
   assert(array.length > favoriteNumber());
   return array.ptr[favoriteNumber()];
}

On Sunday, 25 July 2021 at 17:47:40 UTC, Paul Backus wrote:

module example;

size_t favoriteNumber() @safe { return 42; }

int favoriteElement(ref int[50] array) @trusted
{
    // This is memory safe because we know favoriteNumber returns 42
    @system {
        return array.ptr[favoriteNumber()];
    }
}

And I have already demonstrated, favoriteElement is invalid. You need to have a definition of what favoriteNumber does, and this needs to be reconciled with the definition of favoriteElement.

In this case, favoriteElement is invalid, because favoriteNumber has no formal specification. When reviewing favoriteElement, one must look at it like a black box:

/// Returns: a valid size_t
size_t favoriteNumber() @safe;

int favoriteElement(ref int[50] array) @trusted
{ /* code to review */ }

However, with a specification of favoriteNumber, favoriteElement can be reviewed as correct:

/// Returns: a size_t between 0 and 49, inclusive
size_t favoriteNumber() @safe;

...

Now, when reviewing favoriteElement, I can prove that it's a valid @trusted function given the formal definition of favoriteNumber. If reviewing favoriteNumber, I can reconcile the implementation changes against the spec for it, and know that as long as I follow the spec, I will not mess up any other code. If the spec changes, now you have to re-review anything that uses it (including other @safe code) for correctness.

As I said before, code reviews of @safe functions are still required for correctness, just not for memory safety.

-Steve

On Sunday, 25 July 2021 at 13:14:20 UTC, jfondren wrote:

ulong getAvailableDiskSpace(scope const(char)[] path) @trusted
{
    ULARGE_INTEGER freeBytesAvailable;
    auto err = GetDiskFreeSpaceExW(path.tempCStringW(), &freeBytesAvailable, null, null);
    cenforce(err != 0, "Cannot get available disk space");
    return freeBytesAvailable.QuadPart;
}

Yep. This function today is overly trusted (meaning that parts that can be at least partly mechanically checked are allowed to be checked.

ulong getAvailableDiskSpace(scope const(char)[] path) @trusted
{
    ULARGE_INTEGER freeBytesAvailable;
    auto err = @system GetDiskFreeSpaceExW(path.tempCStringW(), &freeBytesAvailable, null, null);  // expression usage?
    @system{ auto err = GetDiskFreeSpaceExW(path.tempCStringW(), &freeBytesAvailable, null, null); }  // scopeless block?
    cenforce(err != 0, "Cannot get available disk space");
    return freeBytesAvailable.QuadPart;
}

Yes, that's about right. The exact semantics are TBD (scope or no scope, expressions or statements, etc.).

[snip]

I think all of what you are saying is along the same lines as what I'm thinking (though I look at it more as pragmatic reasoning for how to write such functions rather than some "blessed" way to do things).

-Steve

On Sunday, 25 July 2021 at 12:05:10 UTC, Steven Schveighoffer wrote:

phobos$ grep -rP '\W\(\) @trusted' --include '*.d'|wc -l
238
phobos$ grep -rP '\w\(\) @trusted' --include '*.d'|wc -l
111

One thing that is incredibly important to get right here is the way to specify what to do with templates. I've been thinking about this a bit, and even this isn't the right way to do things (specify the function as @trusted and mark the actual trusted part as @system), because you want the compiler to infer @system for certain instantiations, and @trusted for others.

What we need is a way to say "this function should be @trusted iff certain sections of code are inferred @safe".

Perhaps the correct mechanism here is to encapsulate the @trusted parts into separate functions, and make sure the API is @safe (e.g. static inner functions).

I think it would be too confusing to allow @system blocks inside inferred templates.

-Steve