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

[H. S. Teoh]

On Wed, Apr 08, 2020 at 09:14:14PM +0000, IGotD- via Digitalmars-d wrote:
[...]
> 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.

This argument does not make sense.  The whole point of @safe is to
provide mechanically-checked guarantees that it does not do anything
that might corrupt memory.  If it calls a function that is not @safe,
that means the program as a whole does not live up to the promises of
@safe, and therefore should be marked @system.  It does not make sense
to hack it so that you can label a program @safe even though it calls
something that ought to be @system.

If you need to call an FFI function (or whatever other function) and
just want to get the job done, and you don't really care about how @safe
works, then just write @system: at the top of your program and call it a
day. Job done, we can all go home.


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

If they don't care, then their code is @system.  End of story.  I don't
understand why someone would want to jump through hoops to call their
code @safe when it actually isn't.


T

-- 
It only takes one twig to burn down a forest.