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.

On Saturday, 28 March 2020 at 20:24:02 UTC, 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.

Over time we learned that opt-in safety doesn't work and @safe should be the default. Do you think the same will happen with @live?

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.

But what if we want to use these semantics isolated and not turn it on in every function in use?

The alternative I have been proposing is headconst tied to lifetimes, basically a borrowed pointer just with a bit of extra syntax that does propagate within a type.

https://gist.github.com/rikkimax/4cb2cc8ddcac33c1a9bb20de432f9dea

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?


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?

On 28.03.20 22:03, JN wrote:
> On Saturday, 28 March 2020 at 20:24:02 UTC, 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.
> 
> Over time we learned that opt-in safety doesn't work and @safe should be the default. Do you think the same will happen with @live?

Why would this happen? The only thing that @safe and @live have in common is that they are function qualifiers that add additional type checking. @safe is in service of an invariant (memory safety), while @live is not. It's just a linting tool that (from the perspective of memory safety) produces exclusively false positives in @safe code. Also, there is no way to negate it.

On 28.03.20 21:24, Walter Bright wrote:
> @live Ownership/Borrowing system

@live is not an Ownership/Borrowing system, even though it is true that it is based on concepts related to ownership and borrowing.

An Ownership/Borrowing system enforces ownership semantics in @safe code, @live does not. It is a linter for @system and @trusted code with no safety guarantees.

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.

On 29.03.20 04:28, Timon Gehr wrote:
> 
> void qux()@life{

Actually, there is a true positive on this line.

On 29.03.20 04:28, Timon Gehr wrote:
> 
> 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.

Another way to interpret it is to just take it as the statement that everything that is flagged by the linter is a positive, and everything else is a negative. This is the definition of positive and negative.

On Saturday, 28 March 2020 at 20:24:02 UTC, Walter Bright wrote:
> 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.

I have recently added a lot of unittests to my code. That confirmed me that as we all know, it is a mandatory to do if I even a remotely bug-free program is desired :). And that's in a program that already had no global state and used ranges, `final switch`es and `assert`s fairly much.

So I am thinking, perhaps a dead-easy and well known way to test correct `malloc`-`free` pairing in unit tests would work just as well, but be easier to implement and use? It'd be something like this to use:

```
unittest
{   auto tracer = MallocTracer();

    if (true)
    {   auto raiiObject = allocAnObject();
        raiiObject.doSomething();
        assert(tracer.numMallocs == tracer.numFrees - 1);
    }

    assert(tracer.numMallocs == tracer.numFrees);
}
```