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

Walter Bright newshound2 at digitalmars.com
Thu Mar 26 05:43:41 UTC 2020


On 3/25/2020 9:14 PM, Jonathan M Davis wrote:
> In general, a D wrapper library around a C library should be presenting an
> @safe API

A D wrapper should be as thin as possible, which means if the C function being 
wrapped is safe then the D wrapper should be @safe, and if is not safe then the 
D wrapper should be @system.

For the D wrapper developer, since he's providing a service to the D user, part 
of the job will be identifying which of the C interfaces are safe and which are 
system (of course, he can just mark them all as @system just to get things done 
and move on, and it'll be up to the users of said library if that is acceptable 
or not).

> D code does make it much easier to integrate with C code than is the case
> with many other languages, but it also loses a lot of its value if the
> compiler treats C code as if it were @safe even though its memory safety was
> not verified by the compiler, and the programmer gave no indication to the
> compiler that they had verified it. Having the compiler treat C bindings as
> @safe by default would be a huge whole in @safe and make it much harder to
> track down bugs related to memory safety when they occur.

I seriously doubt that would be any harder than it is now.

For those D programmers interfacing with C, they are more sophisticated than raw 
beginners, and it is reasonable to expect them to be capable of adding @system: 
at the start of the module before they go through and check which ones can be @safe.

P.S. I started looking through druntime/src/core/stdc/*.d. They all use @system: 
or @trusted: at the start. Unfortunately, little thought seems to have been put 
into it. For example:

   https://github.com/dlang/druntime/blob/master/src/core/stdc/limits.d#L29

declares everything as @trusted, yet should be @safe. It isn't technically 
broken, but it isn't right.


More information about the Digitalmars-d mailing list