On Sunday, 22 November 2020 at 07:44:51 UTC, Walter Bright wrote:
> I don't expect @live to wind up in the same place as Rust any more than D's functional programming capabilities turn it into Haskell.

It is ok that you only do analysis of the call stack and not the heap, but it has to be context sensitive. You need to analyse all functions that call @live functions and all functions that @live calls.

I read this paper this morning, and I found it to be a nice overview, although covering more ground than alias-analysis:

https://yanniss.github.io/points-to-tutorial15.pdf

You might also consider building on the datalog engine in Z3. It is written in C++, so it should be easy to integrate

On Sunday, 22 November 2020 at 07:44:51 UTC, Walter Bright wrote:
> [snip]
>> and `@live` is just a bunch of checks and dataflow analysis without an underlying modular safety story. Indeed, putting `@safe` on the examples above will correctly reject them.
>
> @live is not redundant with nor a replacement for @safe. It enables a specific set of checks that are independent from @system/@trusted/@safe, though it is best used with @safe.
>
>
[snip]

I haven't had a chance to watch DConf Online yet, but my understanding is that @live would enable more things to be marked as @safe. Is my understanding correct?

On 22.11.20 18:28, jmh530 wrote:
> On Sunday, 22 November 2020 at 07:44:51 UTC, Walter Bright wrote:
>> [snip]
>>> and `@live` is just a bunch of checks and dataflow analysis without an underlying modular safety story. Indeed, putting `@safe` on the examples above will correctly reject them.
>>
>> @live is not redundant with nor a replacement for @safe. It enables a specific set of checks that are independent from @system/@trusted/@safe, though it is best used with @safe.
>>
>>
> [snip]
> 
> I haven't had a chance to watch DConf Online yet, but my understanding is that @live would enable more things to be marked as @safe. Is my understanding correct?

No.

On 22.11.20 08:44, Walter Bright wrote:
> On 11/21/2020 7:37 PM, Timon Gehr wrote:
>> `@live @safe` makes no sense. Per the documentation, `@safe` already ensures memory safety on its own
> 
> Only if you're using the GC to manage memory.

No, always. `@safe` means memory safe, it does not mean you are using the GC.

> @safe does not deal with lining up mallocs and frees.

That's because @safe does not deal with `free` at all. `free` is not memory safe.

> It's also not going to manage the memory of containers (your first example) - the user will be expected to craft the container to take care of that, for example by boxing the owning pointer.
> ...

My point was exactly that `@live` does not help containers manage their lifetimes. You can't create a struct with a `@live` constructor and in `@live` functions the compiler will drop the entire container if you access a single pointer within it.

> 
>> and `@live` is just a bunch of checks and dataflow analysis without an underlying modular safety story. Indeed, putting `@safe` on the examples above will correctly reject them.
> 
> @live is not redundant with nor a replacement for @safe.

My point was that it does not make much sense to use `@live` in `@safe` code, as it can't prevent any additional memory corruption.

> It enables a specific set of checks that are independent from @system/@trusted/@safe, 

Absolutely.

> though it is best used with @safe.
> ...

I highly doubt that. None of your (highly stylized) practical examples of `@live` checks are within `@safe` code.

> 
>> Also, there is no keyword to disable `@live`.
> 
> That's right. If that's the big problem with @live, ..

It really isn't. This point was not a criticism of @live, it is a criticism of the idea to make it the default in that Laser-D project.

> Please understand that the current @live implementation is a prototype.

I do. What I don't understand is where it's supposed to go. I.e., will this ever be anything but a prototype? You can have an idea how it should work before it's fully implemented; it's even typical for a prototype to partially implement some larger vision.

> I expect we'll be learning a lot about how to use it properly. Rust went through considerable evolution, too.

As I said, @live is not closely related to Rust. It performs checks that seem superficially similar to some of the checks in Rust. That's the extent of the similarity. If @live was intended to provide modular safety guarantees like the Rust type system does, it does so in the way some people intended to attract cargo by building life-size models of airplanes out of wood.

Rust had a plan, started with workable designs that were too complicated, then simplified, ergo multiple iterations. Safe memory management via type system was the central point of the language design.
`@live` does not work in this way, it just does some checks. And those checks may or may not be useful in `@system` code under very specific circumstances.

> I don't expect @live to wind up in the same place as Rust

By the way, we _can't_ just copy Rust. Rust's model does not support tracing GC. In the past, I have made specific suggestions for how to approach lifetime management in D.

> any more than D's functional programming capabilities turn it into Haskell.

That's because the central points of Haskell are lazy evaluation and Hindley-Milner type inference, not the (presumed) lack of global state.

On 22.11.20 08:22, Walter Bright wrote:
> 
>> It seems to me that both @live and @safe should be available as compiler flags to turn them on - and not have to rely on annotations. Is this possible? 
>  > Certainly in Laser-D I would like these to be ON by default and annotation
>  > should be to suppress rather than enable.
> 
> My DIP to make @safe the default failed.
> ...

(You could have addressed the problems with the proposal instead of retracting it, in which case it would likely have succeeded.)

> Turning @live on by default would be brutal :-)

It would also be stupid. `@live` is not some sound extension of `@safe`, it's orthogonal and it's really only useful in some niche kinds of `@system` code.

On Sunday, 22 November 2020 at 19:32:59 UTC, Timon Gehr wrote:

> This point was not a criticism of @live, it is a criticism of the idea to make it the default in that Laser-D project.
>

I was thinking mainly about @safe ... @live cannot be made default because user has to decide where it is useful. And as mentioned in another post, I think this probably means it is redundant ...

I personally dislike annotations and would prefer code in Laser-D to be clean - i.e. as noise free as possible. I will probably not document any of the annotations - obviously a  perception is that these things help, but I am not sure there is any real measurable evidence that they are any better than already existing tools such as ASAN or valgrind.

Rust is different because it really goes to the extreme to allow complete object graphs to be memory safe.

On Sunday, 22 November 2020 at 20:33:25 UTC, Dibyendu Majumdar wrote:

>
> Rust is different because it really goes to the extreme to allow complete object graphs to be memory safe.

Actually this statement is incorrect. I meant to say that Rust goes to the extreme to ensure that at compile time it can determine whether an object graph is memory safe. It tries to guarantee that if you can compile it then it is safe (I am excluding unsafe constructs here).

On Sunday, 22 November 2020 at 07:44:51 UTC, Walter Bright wrote:

> Please understand that the current @live implementation is a prototype. I expect we'll be learning a lot about how to use it properly. Rust went through considerable evolution, too. I don't expect @live to wind up in the same place as Rust any more than D's functional programming capabilities turn it into Haskell.


Are there any meaningful code examples using @live to look at and learn?

So far I'm struggling to see how one would write any @live code at all, e.g. how would I create an array of objects and sort it.

Even simpler case I'm struggling with: create a pair of objects, choose one of them dynamically and show it to the user, then release the objects. Something like

struct S { string name; }

@live void show(scope const S* p) { // this works
    writeln(p.name);
}

void release(S *p) { } // consumes the ownership

// how do I make this work?
@live auto longer(scope const S* a, scope const S* b) {
    if (a.name.length > b.name.length)
        return a;
    else
        return b;
}

@live void foo()
{
    auto a = new S("aaa");
    auto b = new S("bb");

    auto c = longer(a,b); // I need a reference to one of them
    show(c);

    release(a);
    release(b);
}

This doesn't compile and I wonder how to fix this.

On 23.11.20 01:21, thedeemon wrote:
> 
> @live void foo()
> {
>      auto a = new S("aaa");
>      auto b = new S("bb");
> 
>      auto c = longer(a,b); // I need a reference to one of them
>      show(c);
> 
>      release(a);
>      release(b);
> }
> 
> This doesn't compile and I wonder how to fix this.

scope c = longer(a,b);

On Sunday, 22 November 2020 at 07:22:22 UTC, Walter Bright wrote:
>
> Turning @live on by default would be brutal :-)

If you take this example.

struct MyStruct
{
	int s;
}

MyStruct*[string] nameLookup;
MyStruct*[int] idLookup;


@live void addStruct(scope MyStruct* s, const string name, int id)
{
	nameLookup[name] = s;
	idLookup[id] = s;
}


void main()
{
	MyStruct* s = new MyStruct;

	addStruct(s, "id1", 1);
}



In the presentation you basically did a copy of the single ownership in Rust. In the function we assign nameLookup and idLookup with a borrowed pointer but not as owners. This currently compiles but your presentation I get the impression that you are going to put D under full single ownership lockdown. If I would remove the scope for the s parameter in addStruct then it would emit an error when trying to assign to idLookup as s is already consumed by nameLookup.