@live questions

[Timon Gehr]

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.