Rationale for accepting DIP 1028 as is

[Bruce Carneal]

On Tuesday, 26 May 2020 at 20:38:17 UTC, Bastiaan Veelo wrote:
> On Tuesday, 26 May 2020 at 16:31:57 UTC, Bruce Carneal wrote:
>> 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 agree that being forced to think about a trusted interface to 
> that routine can contribute to safety. Not getting this is the 
> price if DIP 1028 as is. Doing it the other way bears a 
> different price.
>
> Still, it does not change the amount of code that must be 
> vetted during an audit, either way.
>

If you pick up 100% of the code that the post 1028 compiler lied 
about, then I agree. Unsafe is unsafe even if your compiler stays 
mum.

If you pick up less than 100%, I disagree.  In that situation the 
compiler will have "helped" you to reduce the amount of code to 
be audited.

And finally, were the 1028 extern!(D) default changed to @system, 
I disagree.  The amount of code in non-greenwashed @trusted 
wrappers should be smaller.  (note that I discount the one time 
audit of stable @system libraries)