Fantastic exchange from DConf

[Steven Schveighoffer via Digitalmars-d]

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