Rationale for accepting DIP 1028 as is

[Bastiaan Veelo]

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

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.

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.

-- Bastiaan.