DIP1028 - Rationale for accepting as is

[ag0aep6g]

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.