Rationale for accepting DIP 1028 as is

[Bastiaan Veelo]

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.

-- Bastiaan.