DIP1028 - Rationale for accepting as is

[Arine]

On Sunday, 24 May 2020 at 15:42:54 UTC, ag0aep6g wrote:
> On Sunday, 24 May 2020 at 14:39:50 UTC, Arine wrote:
>> 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.

You *have* to check @system code. That's where you are 
guarantee'd to have memory safety issues. If you are ignoring 
@system code because you think @safe code doesn't interact with 
it at all, then that's a problem you are creating for yourself. 
@system code can still call @safe code, and that @system code 
that is calling the @safe code can pass invalid information that 
causes the @safe code to misbehave. You have to check @system for 
memory safety issues. It seems Walter's comments about only have 
to review @trusted are being taken too literally.