Rationale for accepting DIP 1028 as is

[Bruce Carneal]

On Tuesday, 26 May 2020 at 16:20:23 UTC, Atila Neves wrote:
> On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote:
>> On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote:
>>> [...]
>>
>> Completely agree but my above says nothing about @trusted.
>>
>>> [...]
>>
>> Another distinction: pre 1028 your compilation will error out.
>>  Post 1028 it will not.
>
> Quite the opposite. Most code out there isn't marked as 
> @safe/@trusted/@system. If I add a dub dependency and don't 
> bother with @safe, I can call anything, in any way. Post 
> 1028... nope. Unmarked @system function definitions themselves 
> won't compile.

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?