@system blocks and safer @trusted (ST) functions

[Bruce Carneal]

On Sunday, 25 July 2021 at 09:04:17 UTC, jfondren wrote:
> 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.

It may well have been a fair reading of the past.  I reported on 
the present (yesterday).

>
>> 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.

They are similar in some regards, but if trusted lambdas are the 
only practical option for this type of code going forward, then 
@safe will require manual checking in perpetuity.

I'm not saying mitigating tooling or procedures to cover this can 
not be devised/employed.  I am saying that there is a qualitative 
difference between "the compiler asserts" and "my 
super-duper-xtra-linguistic-wonder-procedure asserts".  Moving 
towards the former is a good idea.  Moving towards the latter is 
not.

>
>> 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.

The initial motivation was concern over @safe practically 
transitioning from "compiler checkable" to "not checkable 
(reported) by the compiler".

>
> 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.

As hopefully understood from my earlier comments, these are, 
qualitatively, not the same thing.  You will still have to check 
a conversion to a new style @trusted function manually of course, 
no work savings there, but you'd gain something pretty important: 
the compiler's assertions regarding your remaining @safe code 
might actually mean something.

Also, I'm not sure how choices (2-to-1 or any N-to-1) made prior 
to the availability of an alternative are to be interpreted.  
What am I missing?

> ...

Finally, thanks for engaging.