Fantastic exchange from DConf

[Dominikus Dittes Scherkl via Digitalmars-d]

On Friday, 19 May 2017 at 20:19:46 UTC, Moritz Maxeiner wrote:
> On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes 
> Scherkl wrote:
>>> You cannot promise to the compiler that the code is memory 
>>> safe since you have no knowledge of what it actually does.
>> No. @trusted is about trust: you cannot rely on the compiler 
>> to verify it, but the code is reviewed by humans.
>
> Precisely. It is about trust the compiler extends to you, the 
> programmer, instead of a mechanical proof (@safe):
>
> "Trusted functions are guaranteed by the programmer to not 
> exhibit any undefined behavior if called by a safe function. 
> Generally, trusted functions should be kept small so that they 
> are easier to manually verify." [1]
I take this to mean the programmer who wrote the library, not 
every user of the library. Ok, it's better the more people 
checked it but it need not be always me.
Hm - we should have some mechanism to add to some list of people 
who already trust the code because they checked it.
>
> If you write an application that uses @trusted code - even from 
> a third party library - *you* are the programmer that the 
> compiler extends the trust to.
This is not my point of view. Especially if I had payed for some 
library, even legally it's not my fault if it fails. For public 
domain ok, the end user is theoretically responsible for 
everything that goes wrong but even there nobody can check 
everything or even a relevant portion of it.

> Trust, but verify: Considering the damages already caused via 
> memory corruption, I would argue that even if you have a list 
> of people you trust to both write @trusted and review @trusted 
> code (both of which is fine imho), reviewing them yourself 
> (when writing an application) is the prudent (and sane) course 
> of action.
This is infeasable even if @safe and @trusted reduce the Herculic 
task by large.

>> Especially basic libraries will over time become tested and 
>> audited by very many people or even organizations. So after 
>> some time they really can be trusted.
>
> Absolutely not. This kind of mentality is what allowed bugs 
> like heartbleed to rot for years[2], or even decades[3]. Unsafe 
> code can never be *inherently* trusted.
In addition to trusted, D has unittests that - in harsh contrast 
to C - are run by most users. And especially @trusted functions 
have extensive tests - even more so if they ever showed some 
untrustworthy behaviour.
This increasing unittest blocks make older and more used 
libraries indeed more reliable, even if a function is changed 
(also in contrast to C where a changed function start again at 
zero trust while a D function has to pass all the old unittests 
and therefore start with high trust level)

>> For bigger projects you always need to trust in some previous 
>> work.
>
> Not really. You can always verify any @trusted code (and if the 
> amount of @trusted code you have to verify is large, then I 
> argue that you are using the wrong previous work with regards 
> to memory safety).
Sorry. Reviewing everything you use is impossible. I just can't 
believe you if you claim to do so.

>> But having the @trusted and @save mechanism makes the 
>> resulting code a whole lot more trustworthy than any C library 
>> can ever be - just by reducing the number of lines of code 
>> that really need be audited.
>
> I agree with that viewpoint (and wrote about the reduced 
> auditing work previously in this conversation), but the quote 
> you responded to here was about using D in general being memory 
> safe (which is binary "yes/no"), not any particular library's 
> degree of trustworthyness with regards to memory safety (which 
> is a continuous scale).
No. Declaring a function @safe is still no binary "yes". I don't 
believe in such absolute values. Clearly the likelyhood of memory 
corruption will be orders of magnitude lower, but never zero. The 
compiler may have bugs, the system a SW is running on will have 
bugs, even hardware failures are possible. Everything is about 
trust.

>> I personally would not going bejond probing some few functions 
>> within a library which I think are more complicated and 
>> fragile, and if I find them ok, my trust in what else the 
>> authors have marked @trusted increases likewise.
>
> That is your choice, but the general track record of trusting 
> others to get it right without verifying it yourself remains 
> atrocious and I would still consider you negligent for doing 
> so, because while in C one has had little other choice 
> historically - since without a @safe concept the amount of code 
> one would have to verify reaches gargantuan size - in D we can 
> (and should imho) only have small amounts of @trusted code.
Of course. And an decreasing amount. But what we have is already 
a huge step in the right direction.
We should live in the reality. Everybodies time is spare. So you 
can always spent your time for checking code only for the parts 
which are most important for you and which you suspect the most. 
Claiming otherwise is - believe it or not - making you less 
trustworthy to me.