@live questions

[Timon Gehr]

On 22.11.20 03:28, Dibyendu Majumdar wrote:
> Hi
> 
> I don't quite know Rust so it is bit hard to compare this feature with 
> Rust. Ideally someone who knows both languages in depth should compare 
> and figure out if @live is comparable to Rust ownership ideas.
> 
> I have following questions / suggestions:
> 
> a) I understand on its own @live is only part of what Rust does? Rust 
> has lifetime annotations and I believe it can track memory allocation 
> across a graph of objects and ensure there is no leak etc. Is my 
> understanding correct that @live only deals with pointers and to compare 
> this to Rust, one has to also include DIP1000?
> ...

@live is not particularly comparable to what Rust does. Rust ensures 
safety modularly, while @live does not. Memory ownership is not built 
into Rust at the language level, only borrowing is. Forcing ownership 
semantics on built-in pointers does not make a lot of sense, as they 
have no associated allocator so pointer deallocation remains unsafe.

> My first suggestion is that @live and DIP1000 features should be 
> documented together. I heard in the discussions that DIP1000 is actually 
> not yet documented?
> 
> b) Is it also the case that DIP1000 is only available if a function is 
> marked @safe?
> ...

`@live` attempts to respect `return` annotations on scoped pointers even 
in @system code.

E.g., this works as expected:
---
import core.stdc.stdlib;
int* foo(return scope int* x)@live{
    return x;
}
@live void main(){
    int* p=cast(int*)malloc(int.sizeof);
    scope int* q=foo(p);
    free(p);
}
---

But I think there isn't really a coherent lifetime design, e.g., this is 
a memory leak:
---
import core.stdc.stdlib;
struct S{int* a,b;}
void main()@live{
     auto q=S(cast(int*)malloc(int.sizeof),cast(int*)malloc(int.sizeof));
     free(q.a);
}
---

And of course, as soon as you use the standard library all bets are off, 
e.g. this is a double free in elegant range notation:

---
import std.range, core.stdc.stdlib;
void main()@live{
     repeat(cast(int*)malloc(int.sizeof),2).each!free;
}
---

It also works with a standard `foreach` loop:

void main()@live{
     foreach(p;repeat(cast(int*)malloc(int.sizeof),2))
         free(p);
}

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

`@live @safe` makes no sense. Per the documentation, `@safe` already 
ensures memory safety on its own 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.

Also, there is no keyword to disable `@live`.