timon.gehr at gmx.ch
Sun Nov 22 19:32:59 UTC 2020
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
> @safe does not deal with lining up mallocs and frees.
That's because @safe does not deal with `free` at all. `free` is not
> 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,
> 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
> 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.
More information about the Digitalmars-d