On Sunday, 24 May 2020 at 14:39:50 UTC, Arine wrote: [...]
It'd be no different than passing the pointer into @safe code as a parameter from @system code. Ultimately the error occurs in @system code and directly as a result of @system code. It is undefined behavior as well. No amount of safe code can save you from that.
I think you're arguing against a point that wasn't made. I'm not saying that there's anything fundamentally unsound about an @system static constructor. As you say, it's the same any other @system function.
I'm just saying that it's another thing you have to check when you want to verify that a program is actually safe.
[...]
Then that is definitely a bug if that's the case. Someone should probably make a bug report, Walter? If you are still using @system with @safe, then that would still be somewhere you have to look for not memory safe code. @trusted should just mean that someone verified it. @system then would mean no one's verified it to be safe, that doesn't mean you don't have to check it.
@system does indicate that you don't have to check a function. But its trumped by other indicators:
* @system entry points (`main`, static constructors, static initializers) - have to check those.
* Foreign prototypes (`extern (C)` and friends) - have to check those, whether they're @system or @safe or @trusted.
* @system functions that are being called by @trusted ones - have to check those. But I would say that's part of verifying @trusted functions.
Other than that (and maybe other special cases that I've missed), you can safely ignore @system functions, because your @safe program cannot possibly be calling them.
