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:
>>> On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote:
>>>> [...]
>>>
>>> The compiler does not and cannot check inside @trusted. 
>>> Whether or not one requires extern(C[++]) to be behind or 
>>> within @trusted does not change what the compiler can or 
>>> cannot check.j
>>
>> Completely agree but my above says nothing about @trusted.
>>
>>>
>>>> [...]
>>>
>>> The amount of code that requires human auditing remains the 
>>> same. What matters is how to find that code, and how to 
>>> maintain the validity of the audits.
>>
>> 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.

I think I see the difficulty.  We both support 1028's elimination 
of the "I can call anything, in any way" default.  I really like 
@safe by default for machine checkable code.  I don't support 
@safe by default for extern C.