Rationale for accepting DIP 1028 as is

[Bruce Carneal]

On Tuesday, 26 May 2020 at 18:06:00 UTC, Bastiaan Veelo 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.
>>
>> Completely agree but my above says nothing about @trusted.
>
> But it matters. Even if your code is @safe, that doesn't mean 
> it is completely safe. Your @safe code can call into somebody 
> else's @safe code that can call @trusted code that calls 
> @system code. If you want to guarantee that your code is safe, 
> you'll have to find and audit the @trusted bits (as well as 
> everything that is called from there).

Agree that the transitive closure is difficult, especially for 
humans.

>
> If extern(C) is implicitly @system, you'll have to make calls 
> @trusted and they are subject to auditing. If extern(C) is 
> implicitly @safe, calls are still subject to auditing. Whatever 
> your preference, I think the compiler can be of greater help in 
> finding the bits that require auditing than grep can, and then 
> the difference isn't all that important anymore. Safe wrappers 
> around C libraries are still written the same way, audited the 
> same way, and unsafe calls into C caught the same way.

Agree.  @trusted doesn't mean that the code so labelled should be 
blindly trusted.  The aim should be reduction of @trusted where 
practical.  Silently letting all extern C functions inside the 
tent is not a reduction.

>
> I agree that making extern(!D) @system looks sound, like the 
> way it should be. But it breaks compilation of existing code, 
> and it is too easy to evade by slapping on an explicit @trusted 
> or (God forbid) @safe. Or we could make extern(!D) to be 
> anything other than @system an error, which would be really 
> annoying. I think that what we all strive for is to reduce the 
> strain of coding as well as to reduce the strain of auditing.

I'm all for reducing the strain of writing correct code.

As others have implied, we're dealing with, at least, two issues 
here: 1) any transition from opt-in to opt-out safety will break 
code.  Some programmers will resort to greenwashing in an effort 
to "fix" it.  Will we be better off post transition? And 2) 
should uncheckable code be considered @safe, ever.