Fantastic exchange from DConf

[Moritz Maxeiner via Digitalmars-d]

On Friday, 19 May 2017 at 11:53:57 UTC, Steven Schveighoffer 
wrote:
> 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.

Agreed 100%.

> This provides a foundation to build completely @safe libraries.

Agreed if you mean libraries being marked completely as @safe 
(which I assume).
Disagreed if you mean libraries that are proven to never corrupt 
memory (not possible with unsafe operating system).

> It's like atomics -- they are hugely important and very easy to 
> get wrong.

Sure.

> Leave the actual implementation to the pros.

If you mean the act of implementing: Yes, agreed.
If you mean the entire mind space of the implementation, aka you 
(the programmer) receives a "get out of audit this" free card, 
because "professionals" wrote it: No. You are *always* 
responsible for verifying *all* third party @trusted code 
*yourself*.

> We should be the pros on phobos/druntime safety.

Agreed.

>
> 2. @trusted blocks in any project need to be considered red 
> flags. You should not need to audit @safe code.

Yes you do, because it can call into @trusted like this:

---
void foo(int[] bar) @safe
{
   () @trusted {
     // Exploitable code here
   }();
}
---

You *must* audit third party @safe code for such hidden @trusted 
code (e.g. grep recursively through such third party code for 
@trusted and verify).

> What you need to do is audit @trusted code when it interacts 
> with @safe code.

You need to audit *all* @trusted code, because you don't 
necessarily control who calls it.

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

s/prove/promise/
But yes, that is precisely what I wrote in the above with regards 
to the reduction of what you have to audit.

>
> If we get into "@safe really means @trusted" territory, we have 
> lost.

For code that you write yourself, @safe means @safe, of course. 
For code other people write and you want to call, it being marked 
@safe does really mean @trusted as long as you yourself have not 
looked inside it and verified there either is no hidden @trusted, 
or verified *yourself* that the hidden @trusted is memory safe.
I consider any other behaviour to be negligent to the degree of 
"you don't actually care about memory safety at all".