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