newshound2 at digitalmars.com
Sun Nov 22 07:44:51 UTC 2020
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.
More information about the Digitalmars-d