@system blocks and safer @trusted (ST) functions

[claptrap]

On Monday, 26 July 2021 at 16:45:07 UTC, jfondren wrote:
> On Monday, 26 July 2021 at 16:26:53 UTC, claptrap wrote:
>> Its a pointless exercise because your example is a red 
>> herring, but this breaks it.
> ...
>> And TBH I'm not even sure what your overall point is.
>
> It's a response to overly strong claims about what this DIP 
> will achieve:
>
> https://forum.dlang.org/post/fnhvydmbguyagcmaepih@forum.dlang.org
>> 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.

If you're saying the proposed "system blocks inside trusted 
functions" provide no advantage over teh current "trusted lambdas 
inside safe functions" yes thats true. But I think the point is 
trusted functions get more checking. Even if you say well you can 
achieve the same by just using a trusted lambda inside a safe 
function its not the same once you consider what people actually 
do.

If you have just one trusted function in your app, then switching 
to this new regime would automatically give you more checking.

You have to take into account how people will actually behave, 
even if you can technically achieve the same thing with the 
current system.


> And it's again from the perspective of someone reviewing a 
> patch rather than someone troubleshooting a bug. *Once there is 
> a memory error in your program*, then @safe helps you by 
> telling you to look elsewhere for the direct violation. If you 
> are reviewing patches with an eye towards not including a 
> memory error in your program, then @safe matters a lot less.

This is still mischaracterizing the problem, if you add safe code 
and it causes a memory error to occur in trusted or system code, 
the problem was already there. You're not adding a memory error, 
just changing the conditions so it is triggered.

It would be nice to have a system that would help with problems 
like that but I think its actually unreasonable, and probably 
impossible. And it's probably counterproductive to use examples 
like that to guide the design process. You're designing for 
constraints that cant be met.