More evidence that memory safety is the future for programming languages

[Timon Gehr]

On 29.03.20 03:08, Arine wrote:
> On Saturday, 28 March 2020 at 23:14:05 UTC, rikki cattermole wrote:
>> On 29/03/2020 9:24 AM, Walter Bright wrote:
>>> https://news.ycombinator.com/item?id=22711391
>>>
>>> Fitting in with the push for @safe as the default, and the @live 
>>> Ownership/Borrowing system for D.
>>>
>>> We can either get on the bus or get run over by the bus.
>>
>> "This is why D requires and @live attribute be added to functions to 
>> enable the checking for just those functions, so it doesn't break 
>> every program out there."
>>
>> Interesting quote there.
> 
> 
> Indeed it is interesting, on one hand, you have @safe being made the 
> default, breaking all code in existence. And then you have @live being 
> introduced so it doesn't break all code in existence. It seems @live is 
> making the same mistake as @safe. How long until @live becomes the default?
> ...

@live will never be the default in any version of D that I am willing to 
use. I really don't understand why people are inclined to think it is on 
the same level as @safe. It just is not.

> 
> I also find this claim to be quite bold:
> 
>> This is why D uses DFA to catch 100% of the positives with 0% negatives.
> 
> When in the review thread previously the sentiment was along the lines 
> of, "patch the holes as they appear". So how do you go from patching 
> holes as they appear, to 100% guaranteeing it catches everything 
> correctly, without thorough testing. Or is that just empty marketing 
> promises?
> 

It's not a statement that has a standard meaning. What positives and 
what negatives? Refer to the following table:

                        | problem exists | problem does not exist
----------------------------------------------------------------
flagged by linter      | true positive  | false positive
----------------------------------------------------------------
not flagged by linter  | false negative | true negative
----------------------------------------------------------------

@live leads to any of the four kinds of outcomes:

void foo(int *p)@live{
     free(p);
     free(p); // true positive
}

void bar(int *p)@live{
     auto q=p;
     *p=3;    // false positive
}

void baz()@live{
     auto p=new int;
     free(p); // false negative
}

void qux()@life{
     auto p=cast(int*)malloc(int.sizeof);
     free(p); // true negative
}

An amusing way to interpret 100% positives and 0% negatives would be to 
say the linter flags all positives (either true or false) and no 
negatives (neither true nor false). That basically means the linter 
flags every code as being problematic, which would make it completely 
useless.

In the thread on hackernews, there were a few people who interpreted the 
statement as saying that the linter has neither false positives nor 
false negatives, which is provably impossible. You can get rid of one of 
them at a time, but not both. @safe is an example of a feature that does 
not have false negatives (unless the implementation is buggy), but of 
course it has loads of false positives, for example you cannot manage 
memory manually in @safe code without @trusted escapes, even if you do 
it correctly.