On 5/4/2025 11:03 AM, Dukc wrote:
> Like I wrote above, you can only depend on `@live` for `@safe`ty if you use it everywhere.
It doesn't have to be all or nothing in order to be useful. Just like we use @safe on some functions, and @system on others.

On 05/05/2025 8:50 AM, Walter Bright wrote:
> The point of the borrow checker is to ensure there is exactly one point of origin for a pointer and exactly one point of termination for it.

Hang on, that isn't the point of it at all.

A borrow checker has got the _side effect_ of only having one entry and exit point for an object.

But the _objective_ is to loosen the restrictions that an _ownership transfer system_ imposes on the type system whilst keeping its guarantees.

We do not have an ownership transfer system in D. Therefore we cannnot have a borrow checker.

What we do have is a liveliness analysis with guaranteed modelability, and we do have a use for that, @restrict.

Enforcing @restrict could be an incredibly useful tool to those who do data processing with simd, right now they are doing this by hand.

On Sunday, 4 May 2025 at 11:02:27 UTC, Paul Backus wrote:
> 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.

Walter's admission that he has not written even a single line of Rust code raises a similar concern. Reading Rust documentation is necessary but not sufficient for acquiring a real understanding of the borrow checker (would you get into a self-driving car having software written by someone who doesn't drive?). I've written about 10000 lines of working Rust code, so while I would not claim to be the world's preeminent expert on the language, I've been in the trenches with it. You cannot learn from reading a book what this taught me.

This also strikes me as an instance of gluing yet another wart onto this language.

On 5/7/25 16:47, jmh530 wrote:
> 
> I can think of a few different ways forward (by no means limited to just this)

Well, the big issue here is that @live is still not transitive. A function attribute is not really the right way to go about this anyway. Aliasing is a property of a pointer, not a function.

On Wednesday, 7 May 2025 at 23:21:12 UTC, Timon Gehr wrote:
> On 5/7/25 16:47, jmh530 wrote:
>> 
>> I can think of a few different ways forward (by no means limited to just this)
>
> Well, the big issue here is that @live is still not transitive. A function attribute is not really the right way to go about this anyway. Aliasing is a property of a pointer, not a function.

And this is exactly what Rust does with the borrowed/raw pointer distinction. Walter how can you claim to have studied the Rust spec yet miss and/or disregard this fundamental detail? And do not bring up that extremely outdated and irrelevant example of near/far pointers in DOS.