Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[Paolo Invernizzi]

On Saturday, 4 April 2020 at 06:53:57 UTC, Walter Bright wrote:

> D's C interface has always relied on the user to get right. 
> Recall that C doesn't do any name mangling at all:
>
>   ----- mylib.di
>     extern (C) int addOne(int i);
>
>   ----- mylib.c
>     double addOne(double d) { return d + 1; }
>
>
> That'll link fine and yet fail at runtime. Oops! Calling it 
> @system will not help at all. If the C implementation is bad, 
> there's not a damn thing D can do about it, with or without 
> @system. It's always going to be this way.

That's not what we are discussing: we are discussing about 
"memory safety", and marking an extern(C) declaration with 
@trusted simply tells the reviewer to verify the C API, and check 
that the programmer has done no mistakes as "really", the C 
function can't corrupt memory. The same for @trusted wrapper.

I don't want to add more burden to reviewers (check that @system: 
is present, or what-so-ever different solution) I want MORE 
mechanical checks and LESS reviewer work.

It's the review of written code the bottleneck in most of 
companies, not writing code. That's also why I don't like  DIP 
1032, readability is much more important over syntactic sugars 
rules.