On 5/19/17 5:12 AM, Moritz Maxeiner wrote:
On Thursday, 18 May 2017 at 12:12:18 UTC, Steven Schveighoffer wrote:
[...]
We still allow unsafe operations inside @safe code, using @trusted.
This is a necessary evil, but it's so very important that the base
libraries (druntime and phobos) keep this to a minimum, and that we
review those @trusted blocks to death.
That and we need to make sure it is understood by everyone using third
party @safe code that it is *not* a "I don't have to audit this code"
free card. It merely reduced the amount of code you need to review to
what is marked as @trusted (with regards to memory safety); as long as
you don't *know* whether some third party code is @safe or @trusted, you
(as the programmer) have to assume it is @trusted and that means you
have to extend trust to the author and cannot assume any of the @safe
guarantees for that code.
What we need are 2 things:
1. @trusted blocks need to be rock-solid in Phobos and Druntime. And as
rare as possible. This provides a foundation to build completely @safe
libraries. It's like atomics -- they are hugely important and very easy
to get wrong. Leave the actual implementation to the pros. We should be
the pros on phobos/druntime safety.
2. @trusted blocks in any project need to be considered red flags. You
should not need to audit @safe code. What you need to do is audit
@trusted code when it interacts with @safe code. If you can prove that
in *all cases* the @safe code is still @safe even with the included
@trusted blocks, then you don't have to audit @safe code that calls that
"tainted" function.
If we get into "@safe really means @trusted" territory, we have lost.
-Steve
