@live questions

[Walter Bright]

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. @safe does not deal with lining up 
mallocs and frees. 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.


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


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

That's right. If that's the big problem with @live, I'd consider @live a 
resounding success :-/

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.