@system blocks and safer @trusted (ST) functions

jfondren julian.fondren at gmail.com
Mon Jul 26 16:45:07 UTC 2021


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.

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.


More information about the Digitalmars-d mailing list