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

[IGotD-]

On Wednesday, 8 April 2020 at 20:47:40 UTC, Steven Schveighoffer 
wrote:
>
> The only reasonable case where extern(C) code that is actually 
> @system should be prototyped @trusted is when the code isn't 
> written in D. In that case, it's not possible to mark it 
> @trusted, but one can reasonably assume that the code is 
> technically @safe. For instance libc's cos() or something 
> similar.
>
> extern(C) code that is not checked @safe SHOULD NEVER be 
> prototyped @safe. But it makes no sense to prevent extern(C) 
> code that is @safe from being prototyped as @safe. Requiring 
> one to write @trusted doesn't change anything as the code is 
> still callable via @safe code, and just creates unnecessary 
> annoyances.

Just to make a counter argument against extern(C) being @system 
by default which is perhaps a bit counter intuitive. The 
programmer wants get things done fast and in practice the 
programmer doesn't care about if the FFI functions are @safe or 
@system. The programmer just want to call the FFI function the 
@safe function just as usual. In practice a programmer will 
almost every time put @safe or @trusted for every function that 
are imported.

Semantically having extern(C) @system makes sense but from a 
language usability point of view, every programmer will want to 
convert these in order to call the directly from @safe code 
without any wrapper. Programmers don't care (like a honey 
badger), they just want to call their code.