@system blocks and safer @trusted (ST) functions

[Steven Schveighoffer]

On Sunday, 25 July 2021 at 13:14:20 UTC, jfondren wrote:
>
> OK. I'll argue the opposite position for a bit, then.
>
> Here's a @trusted function with a non- at safe component:
>
> ```d
> 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.

>
> With this proposal, I imagine:
>
> ```d
> 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]

> Does that sound about right?

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