DIP1028 - Rationale for accepting as is

[Walter Bright]

On 5/26/2020 5:20 AM, Johannes T wrote:
> On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
>> [..]
> 
> Thank you very much for your patience with all the negative feedback. I get your 
> decision to not annotate extern C with @system by default. The biggest issue 
> with extern @system is that @trusted would become less useful when dealing with 
> declarations and bindings. @trusted would appear more frequently. We wouldn't be 
> able to assume that the author put in effort in assessing the trustworthiness of 
> a declaration. More greenwashing, less safety. Those are severe drawbacks, I agree.
> However, as Andrei pointed out, PR is a huge problem. We need to be able to sell 
> it with a straight face.

Frankly, I feel that if I could sit down with you folks, I can get the idea 
across what I'm trying to accomplish.

> I think this might be done by formally redefining the meaning of safety 
> attributes when applied to extern:
> The safety of extern can't be assessed by the compiler. Implicit "@safe" extern 
> within @safe code is accepted for the convenience of the average user. Explicit 
> @system or @trusted can be added for desired behavior.
> I think this can be explained.

I do, too. But apparently not by typing.

> It's not an acceptable solution for people who require correctness. ZombineDev 
> can't tell an auditor that he relies on D-Scanner to find the problematic spots. 
> I believe it's unavoidable to provide an option to change the default. It could 
> make extern @system or refuse to compile safe code calling @safe extern.

People who require correctness are going to have to manually audit each and 
every C declaration regardless. There's no way around it. A less strict auditor 
would focus his attention on un-annotated declarations and assume that annotated 
ones are annotated correctly.