Rationale for accepting DIP 1028 as is

[Gregory]

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:
>>>> 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.

Which will just lead people to pure @trusted: at the top of their 
code to get it to compile again, with or without extern(C) being 
@safe by default. Then someone that uses it as dependency will 
mistaken think it is @safe. What's to stop this kind of 
"greenwashing" and why is greenwashing only important to prevent 
when talking about extern(C) but every other code that will break 
from this change?