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

[Jonathan M Davis]

On Wednesday, March 25, 2020 11:43:41 PM MDT Walter Bright via Digitalmars-d 
wrote:
> 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).

There is a huge difference between providing bindings for a C library and
providing a D wrapper library for a C library. IMHO, how thick the D wrapper
should be very much depends on the C code in question, but in general, I
would expect a D wrapper library to be trying to present a D API with the
niceties that go with that, which does not necessarily mean that the wrapper
is thin. Sometimes, a thin wrapper works just fine, but in general, if a
wrapper is thin, then IMHO, it's providing very little value over simply
using the C bindings directly and thus is of questionable utility.

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

The problem is not that it's hard to mark extern(C) declarations as @system.
The problem is that if they're automatically @safe, then it's harder to
track them down when there's an @safety bug. It should always be possible to
segregate memory safety bugs in @safe code by looking for @trusted code that
it's calling. I don't think that _anything_ should be considered @safe
unless the compiler has actually verified that it is, with @trusted of
course being used to indicate that the programmer claims to have verified
it. extern(C) declarations cannot be verified by the compiler and thus
should never be considered @safe. At most, the programmer should be marking
them with @trusted.

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

That's concerning, since it implies that whoever did it was just slapping
@trusted on the various C declarations. Honestly, I'm inclined to argue that
using @trusted with : or {} is just plain bad practice. Non-extern(D)
functions need to be individually verified and thus should be marked
individually.

- Jonathan M Davis