@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