@system blocks and safer @trusted (ST) functions

[Bruce Carneal]

On Sunday, 25 July 2021 at 14:36:27 UTC, Paul Backus wrote:
> On Sunday, 25 July 2021 at 14:19:47 UTC, Bruce Carneal wrote:
>> On Sunday, 25 July 2021 at 13:42:52 UTC, Paul Backus wrote:
>>> On Sunday, 25 July 2021 at 12:56:33 UTC, Bruce Carneal wrote:
>>>> 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.
>>>
>>> Memory safety is a global property. If even a single line of 
>>> your new-style `@system`-block (or old-style `@trusted` 
>>> lambda) causes undefined behavior, it does not matter one bit 
>>> what the compiler asserts about the `@safe` code in your 
>>> program: the entire process is corrupted.
>>
>> I do not know of any competent programmer who would say 
>> otherwise.
>>
>> I also do not know what this has to do with a discussion 
>> regarding debasing/improving @safe.  What am I missing?
>
> It is a response to the claim that "the compiler's assertions 
> regarding your remaining @safe code might actually mean 
> something." They mean exactly the same thing with your proposal 
> as they do without it: that the `@safe` portion of the program 
> does not violate the language's memory-safety invariants 
> directly.

They don't mean the same thing to me.  In one case @safe 
invariants are asserted with a process that limits human error to 
group-visible forms (compiler errors in the code handling @safe). 
  In the other case we add in a more direct form of human error, 
the failure to correctly review "@safe" code that contains 
trusted lambdas.

In one case, your @safe code comes in one flavor, machine 
checkable.  In the other case your @safe code comes in two 
flavors, machine checkable and needs-human-intervention since you 
have no opportunity to segregate to the new @trusted form.