@system blocks and safer @trusted (ST) functions

[jfondren]

On Sunday, 25 July 2021 at 08:16:41 UTC, Bruce Carneal wrote:
>> Of the current behavior, Walter's said that he doesn't want 
>> @trusted blocks because they should be discouraged in @safe 
>> code. With this change, we'll have exactly what he doesn't 
>> want with different names: s/@trusted/@system/, 
>> s/@safe/@trusted/, and the exact same behavior: @system blocks 
>> are just what @trusted blocks would've been, and @trusted code 
>> with @system blocks in it is just @safe code with a different 
>> name.
>
> I think you're misreading Walter on this.  He was the one who 
> recommended that I pursue this DIP at beerconf (it was just an 
> idea that I'd thrown out up to that point).

I think it's a fair reading of 
https://www.youtube.com/watch?v=nGX75xNeW_Y&t=379s

 From "With this change"&c that's all in my voice.

> I'd like to localize system code and minimize un-automated 
> checking.  An @trusted lambda in an @safe function goes in the 
> other direction.

Presently, when you write a function that you want to be mostly 
@safe but that needs to break those restrictions in part, you 
call it @safe and you put the violation in a @trusted lambda. 
With your proposal, when you write a function that you want to be 
mostly @safe but that needs to break those restrictions in part, 
you call it @trusted and you put the violation in a @system block.

These seem to me to be so identical that I don't see how they can 
be moving in opposite directions. You need to audit the same 
amount of code, and you find that code with the same exertion of 
effort.

> No need to be sorry at all.  If, broadly, people are happy 
> about the current state of affairs and see no significant 
> benefit to truth-in-naming, consistent nesting, and @safe 
> checking within @trusted functions then we'll stick with what 
> we've got.

I feel like you've started with this problem, "@trusted functions 
don't benefit from @safe checking at all", and you've found what 
seems like a good solution to it, but you haven't stepped back 
from your solution to realize that you've worked your way back to 
the existing state of affairs.

If someone shows you some code with a long @trusted function, and 
you would like @safe checks in it, you can change it to a @safe 
function with @trusted lambdas. You can do that right now, and 
that completely solves the problem of @trusted functions not 
getting checked. And this is the 2-to-1 choice of @trusted in 
Phobos. A new option of "you can leave it as @trusted and add 
@system blocks" is just the same option that you already have.

(Although if you skip back from the timestamp above, Walter 
points out that @trusted blocks might not get inlined in some 
cases. A deliberate language feature wouldn't have that problem.)