You add:

```
@live:
```

at the beginning of your modules.

Because it is opt-in with D rather than opt-out in Rust, does not alter the fact that D has a borrow checker.

In Rust you can use "unsafe" to avoid the borrow checker.

On 5/2/2025 12:25 PM, Timon Gehr wrote:
> `@live` however does not give you additional hard guarantees,
It gives the guarantee of a borrow checker - one mutable owner, and many immutable non-owners.

The other safety checks needed (like array overflow checks and escaping stack pointers) are already in the language.

On 5/3/25 21:22, Walter Bright wrote:
> You add:
> 
> ```
> @live:
> ```
> 
> at the beginning of your modules.
> 
> Because it is opt-in with D rather than opt-out in Rust, does not alter the fact that D has a borrow checker.
> 
> In Rust you can use "unsafe" to avoid the borrow checker.

These are disconnected and cherry-picked operational points without taking into account the semantics. Even if you added `@live @safe` on top of all your modules, you still would not get any aliasing guarantees.

```d
@live @safe:
class C{ int* x; }

void main(){
    auto x=new int;
    auto c=new C;
    c.x=x;
    auto y=c.x;
    assert(x is y);
    imported!"std.stdio".writeln(x,y);
}
```

On 5/3/25 23:30, Walter Bright wrote:
> On 5/2/2025 12:25 PM, Timon Gehr wrote:
>> `@live` however does not give you additional hard guarantees,
> It gives the guarantee of a borrow checker - one mutable owner, and many immutable non-owners.
> ...

It does not.

> The other safety checks needed (like array overflow checks and escaping stack pointers) are already in the language.

Whether a safety check is "needed" depends on what invariants the type system is able to establish and rely on in `@safe` code.

I did not bother to support class dereferencing in the implementation due to the lack of interest in it.

D has a lot of higher level constructs (like classes) that require careful implementation in the borrow checker. That doesn't mean the approach is unsound.

On 5/3/2025 2:47 PM, Timon Gehr wrote:
> It does not.

See my other reply regarding higher level pointer constructs.


> Whether a safety check is "needed" depends on what invariants the type system is able to establish and rely on in `@safe` code.

If you can enumerate the other safety checks D needs to be memory safe, I'm listening.

On 5/4/25 03:26, Walter Bright wrote:
> I did not bother to support class dereferencing in the implementation due to the lack of interest in it.
> 
> D has a lot of higher level constructs (like classes) that require careful implementation in the borrow checker. That doesn't mean the approach is unsound.

No classes are needed, I just did that for readability.

```d
@live @safe:

void main(){
    auto x=new int;
    auto c=new int*;
    *c=x;
    auto y=*c;
    assert(x is y);
    imported!"std.stdio".writeln(x,y);
}
```

On 5/4/25 03:30, Walter Bright wrote:
> On 5/3/2025 2:47 PM, Timon Gehr wrote:
>> It does not.
> 
> See my other reply regarding higher level pointer constructs.
> ...

Well, let's continue that discussion in the other subthread.


> 
>> Whether a safety check is "needed" depends on what invariants the type system is able to establish and rely on in `@safe` code.
> 
> If you can enumerate the other safety checks D needs to be memory safe, I'm listening.

E.g., null checks. x)

My point is that this is an _inductive invariant_. You have to state what the invariant is, then you must prove that all execution steps of the program maintain this invariant and in turn you can rely on the invariant holding when you show memory safety.

This is a _design problem_. You don't _need_ any compile-time checks to have a memory safe language, you just need them if there are performance/expressiveness considerations.

`@safe` with DIP1000 and GC is fine in terms of memory safety, ignoring some bugs. It's just not very expressive.

`@live` does not add additional expressiveness to memory safe D, there is no new `@safe` code that it enables. This is because it does not actually expand the type system invariant in a way that could then be relied upon.

On Saturday, 3 May 2025 at 19:22:20 UTC, Walter Bright wrote:
> You add:
>
> ```
> @live:
> ```
>
> at the beginning of your modules.

Even if you do this, you still cannot manually free memory in @safe code, like you can in Rust.

Borrow checking, in itself, is not a useful feature--it's just a bunch of arbitrary hoops the programmer has to jump through. It is useful in Rust ONLY because of the additional safety analysis it enables. In D, the borrow checker does not enable any additional safety analysis, so why would the programmer ever want to jump through its hoops?

On Saturday, 3 May 2025 at 19:22:20 UTC, Walter Bright wrote:
> In Rust you can use "unsafe" to avoid the borrow checker.

Also, this is not true, which you would know if you had read literally anything about unsafe Rust:

> You can take five actions in unsafe Rust that you can’t in safe Rust, which we call unsafe superpowers. Those superpowers include the ability to:
>
> * Dereference a raw pointer
> * Call an unsafe function or method
> * Access or modify a mutable static variable
> * Implement an unsafe trait
> * Access fields of a union
>
> It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks

Source: https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html

This page is the first result on Google for "unsafe rust". The fact that you got this wrong shows very clearly that you have not done your homework on this topic.