DIP1028 - Rationale for accepting as is

[Arine]

On Sunday, 24 May 2020 at 01:26:02 UTC, ag0aep6g wrote:
> On 24.05.20 02:55, Arine wrote:
>> That works even if you make the static this() @safe, and 
>> remove the pointer incrementation.
>
> Sure. `*p = 13;` is perfectly @safe. The static constructor 
> isn't needed for that part. You can just as well do the 
> assignment in `main`. The static constructor is another feature 
> that can smuggle unsafe code (the increment) into your program 
> without the @trusted warning label.

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.

>> You'd have to make the p initialization @safe.
>> 
>>      @safe:
>>          int* p = cast(int*) &x; // error
>> 
>> But note this doesn't work:
>> 
>>      @safe int* p = cast(int*) &x; // compiles
>> 
>> Having the default become @safe will help detect this, as I 
>> don't imagine that is a whole lot of usage of @safe: to begin 
>> with.
>
> The example compiles with `-preview=safedefault`. And even if 
> that gets changed, it will probably still compile when marked 
> @system. So we still won't find it when looking for "@trusted".

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.