Rationale for accepting DIP 1028 as is

[Patrick Schluter]

On Wednesday, 27 May 2020 at 10:46:11 UTC, Walter Bright wrote:
> On 5/27/2020 2:34 AM, Bastiaan Veelo wrote:
>> On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
>>> On 5/26/2020 11:20 PM, Bruce Carneal wrote:
>>>> I'm not at all concerned with legacy non-compiling code of 
>>>> this nature.
>>>
>>> Apparently you agree it is not an actual problem.
>> 
>> Really? I don't know if you really missed the point being 
>> made, or you're being provocative. Both seem unlikely to me.
>
> His argument was:
>
> "Currently a machine checked @safe function calling an 
> unannotated extern C routine will error out during compilation. 
> This is great as the C routine was not machine checked, and 
> generally can not be checked.  Post 1028, IIUC, the compilation 
> will go through without complaint.  This seems quite clear.  
> What am I missing?"
>
> I replied that it was unlikely that such legacy code existed.
>
> He replied that he was not concerned about it.
>
> I.e. working legacy code is not going break.

The legacy code is not the issue, never was.
It always was about unsafe code that will become @safe with that 
DIP.
Safe code is safe and DIP doesn't change that.
It's all about UNSAFE code becoming magically labelled SAFE by 
the compiler but that is still UNSAFE in reality.