Rationale for accepting DIP 1028 as is

[Atila Neves]

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:
>>> On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote:
>>>
>>> @safe: the compiler checks
>>
>> 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.
>
>>
>>> @safe post 1028: the compiler checks, sometimes, just not in 
>>> the scary parts
>>
>> 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.