Simplification of @trusted

[H. S. Teoh]

On Wed, Jun 16, 2021 at 05:59:19PM +0000, IGotD- via Digitalmars-d wrote:
[...]
> I have a better idea, throw it all out. What is @safe? It's a
> limitation of operations you can do in D that might cause memory
> corruption, like pointer casts and such. Wouldn't be enough that the
> programmer self know about this and do not use those potentially
> harmful operations? That would be enough according to me but let's say
> that the programmer doesn't remember what is unsafe/safe. Then a
> compiler switch that gives a warning would be enough, at least for me.

This is a gross misunderstanding of @safe.

The whole point of @safe is to minimize human error.  Trusting the
programmer to know better is what led to C's design with all of its
security holes.  Why bother with array length when we can just trust the
programmer to do the right thing?  Why not just pass bare pointers
around and freely cast them to/from void*, since the programmer ought to
know whether it's safe?

The last several decades of security flaws involving buffer overflows,
memory corruption, and all of that nice stuff is proof that the
programmer CANNOT be trusted.  Programs are too complex for a human to
write flawlessly.  We need to mechanically verify that stuff is safe so
that (most) human errors are caught early, before they get deployed to
production and cause massive damage.

Of course, due to Turing completeness and the halting problem, you can
never mechanically verify 100% of the code.  Especially in system code,
sometimes you DO need to trust that the programmer knows what he's
doing. E.g., if you want to write a GC.  So sometimes you need an escape
hatch to allow you to go outside the @safe box.

The whole idea behind @safe/@trusted/@system is that you want to allow
the human to go outside the box sometimes, but you want to *minimize*
that in order to reduce the surface area of potential human error. So
most code should be @safe, and only occasionally @trusted when you need
to do something the compiler cannot mechanically check.

IOW, reduce the room for human error as much as possible. Even if we can
never eliminate it completely, it's better to minimize it rather than do
nothing at all.


> I couldn't care less about this safe/unsafe and it just gets in the
> way.

If you don't care about @safe, then why not just write @system code?
@system code is allowed to freely call into @safe without any
restrictions.  You won't even need to know @safe exists if you don't use
it.


> It is also clear that despite you want to automate safe code
> verification, you are unable to do so and the responsibility falls to
> the programmer anyway.  That you are unable to solve how FFI should
> act (remember the famous DIP 1028) is also a reminder of that.

This is not an an all-or-nothing binary choice.  *Ideally* we want to
mechanically verify everything.  But since that's impossible (cf.
halting problem), we settle for mechanically verifying as much as we
can, and leave the rest as @trusted blocks that require human
verification.  It's a practical compromise.  It's proven that mechanical
checks DO catch human errors, even if they won't catch *all* of them.
It's better to catch *some* of them than none at all (cf. the past, oh,
30+ years of security exploits caused by C/C++'s lack of automated
checks?).


T

-- 
MAS = Mana Ada Sistem?