On Monday, 14 February 2022 at 21:02:31 UTC, Timon Gehr wrote:
>
> @live does not do what an ownership/borrowing system is supposed to do. I have tried to make this point many times, but most people seem to still assume the opposite. I really don't understand why. The proposed design has been public for a long time now and it's actually immediately obvious that it's pretty much useless in @safe code, as @live is a function annotation.
>

The borrow/checker system and ownership are two separate things. Borrow/checker ensures that there is only one mutable access at one time or several immutable accesses.

Ownership is a completely different topic which connects to memory management. The infamous ownership system in Rust only allows one ownership at one time which is tied to their move semantics.

The borrow/checker in D is something I haven't completely understood and what question it is supposed to solve.

On Monday, 14 February 2022 at 15:50:31 UTC, H. S. Teoh wrote:
>
> The problem with @safe as it is implemented today is that it's implemented as a blacklist rather than a whitelist.
>
> Cf. points 2 and 3 (as applied to memory safety) in:
>
> 	http://ranum.com/security/computer_security/editorials/dumb/index.html

I think @safe has done a fundamental error to allow raw pointers. In @safe code the memory management should be completely opaque similar to C#/Java/whatever, which in turns makes the language more simple to work with. Instead D does the opposite and adds stuff which makes memory management more complicated.

On Monday, 14 February 2022 at 21:14:08 UTC, Elronnd wrote:
> On Monday, 14 February 2022 at 21:02:31 UTC, Timon Gehr wrote:
>> @live is only useful in @trusted or @system code as a linting tool.
>
> Devil's advocate: @nogc.

@live does not help at all with writing @safe @nogc code.

In order for @safe or @trusted code to rely on @live's ownership invariants (e.g., "a non-scope pointer owns the memory it points to"), it must be impossible for @safe code to violate those invariants. Since @live's invariants are only enforced in @live functions, and @safe code is allowed to call non-@live functions, it follows that @safe code is allowed to violate @live's invariants, and therefore that those invariants cannot be relied upon by @safe or @trusted code.

To fix this, you would have to introduce new rules such as

* All @safe functions must also be @live
* @safe functions cannot call non-@live functions

Of course, adding rules like this would break literally every @safe function in every existing D project, so it is totally infeasible in practice--and that's why the current design for @live is a dead-end.

On 2/14/2022 5:15 AM, Paul Backus wrote:
> Huh? My understanding is that modulo compiler bugs and incorrect use of @trusted, @safe code should be 100% memory safe, even without @live.
> What adding an ownership/borrowing system does (or should do) is, like DIP 1000, make it possible to do things in @safe code that previously required @system/@trusted--in this case, things like manually freeing memory.

Without @live, one cannot be protected against things like double frees.

On 2/14/2022 1:43 PM, IGotD- wrote:
> The borrow/checker system and ownership are two separate things. Borrow/checker ensures that there is only one mutable access at one time or several immutable accesses.
> 
> Ownership is a completely different topic which connects to memory management. The infamous ownership system in Rust only allows one ownership at one time which is tied to their move semantics.
> 
> The borrow/checker in D is something I haven't completely understood and what question it is supposed to solve.

@live only allows one ownership at a time and is tied to move semantics.

On Monday, 14 February 2022 at 22:47:24 UTC, Walter Bright wrote:
> On 2/14/2022 5:15 AM, Paul Backus wrote:
>> Huh? My understanding is that modulo compiler bugs and incorrect use of @trusted, @safe code should be 100% memory safe, even without @live.
>> What adding an ownership/borrowing system does (or should do) is, like DIP 1000, make it possible to do things in @safe code that previously required @system/@trusted--in this case, things like manually freeing memory.
>
> Without @live, one cannot be protected against things like double frees.

If you're writing @safe code you're already protected from double frees because you're not allowed to manually free memory at all, never mind doing it twice. :)

On 2/14/22 22:43, IGotD- wrote:
> On Monday, 14 February 2022 at 21:02:31 UTC, Timon Gehr wrote:
>>
>> @live does not do what an ownership/borrowing system is supposed to do. I have tried to make this point many times, but most people seem to still assume the opposite. I really don't understand why. The proposed design has been public for a long time now and it's actually immediately obvious that it's pretty much useless in @safe code, as @live is a function annotation.
>>
> 
> The borrow/checker system and ownership are two separate things. 

That's why I mentioned both. The stated goal of @live is to have some story related to both of those things. I think it's not a particularly good story compared to some of the competition.

> Borrow/checker ensures that there is only one mutable access at one time or several immutable accesses.
> ...

That's just one way to organize borrowing. @live has some checks that aim in this direction, but it does not have a consistent explanation in terms of what it is ensuring.

> Ownership is a completely different topic which connects to memory management.

I am not sure what your point is. "Completely different topic" makes little sense, as there is no need for borrowing if you have no ownership. Also, of course, borrowing "connects to memory management" too.

> The infamous ownership system in Rust only allows one ownership at one time which is tied to their move semantics.
> ...

Which of course has no relation at all to why Rust also has an infamous borrow checker. Got it.

> The borrow/checker in D is something I haven't completely understood and what question it is supposed to solve.

I am pretty sure I understand it completely, and that calling it a borrow checker is somewhat misleading.

On Monday, 14 February 2022 at 13:15:26 UTC, Paul Backus wrote:
> On Monday, 14 February 2022 at 08:39:58 UTC, Walter Bright wrote:
>> On 2/13/2022 3:15 AM, Florian Weimer wrote:
>>> I've tried to figure out where this is heading. Is the eventual goal (irrespective of mechanism) that sticking `@safe` onto the `main` function will ensure memory safety for the whole program?
>>
>> Yes, although @safe does not supply complete memory safety. The addition of @live fills in much of the rest.
>
> Huh? My understanding is that modulo compiler bugs and incorrect use of @trusted, @safe code should be 100% memory safe, even without @live.
>

Yes, @live really isn't necessary for memory safety.

On Monday, 14 February 2022 at 22:47:24 UTC, Walter Bright wrote:
> On 2/14/2022 5:15 AM, Paul Backus wrote:
>> Huh? My understanding is that modulo compiler bugs and incorrect use of @trusted, @safe code should be 100% memory safe, even without @live.
>> What adding an ownership/borrowing system does (or should do) is, like DIP 1000, make it possible to do things in @safe code that previously required @system/@trusted--in this case, things like manually freeing memory.
>
> Without @live, one cannot be protected against things like double frees.

Free is not @safe , so there is nothing to protect against.

On Monday, 14 February 2022 at 22:46:09 UTC, Paul Backus wrote:
> On Monday, 14 February 2022 at 21:14:08 UTC, Elronnd wrote:
>> On Monday, 14 February 2022 at 21:02:31 UTC, Timon Gehr wrote:
>>> @live is only useful in @trusted or @system code as a linting tool.
>>
>> Devil's advocate: @nogc.
>
> @live does not help at all with writing @safe @nogc code.
>
> In order for @safe or @trusted code to rely on @live's ownership invariants (e.g., "a non-scope pointer owns the memory it points to"), it must be impossible for @safe code to violate those invariants. Since @live's invariants are only enforced in @live functions, and @safe code is allowed to call non-@live functions, it follows that @safe code is allowed to violate @live's invariants, and therefore that those invariants cannot be relied upon by @safe or @trusted code.
>
> To fix this, you would have to introduce new rules such as
>
> * All @safe functions must also be @live
> * @safe functions cannot call non-@live functions
>
> Of course, adding rules like this would break literally every @safe function in every existing D project, so it is totally infeasible in practice--and that's why the current design for @live is a dead-end.

This is 100% correct.

In addition, taking a step back, it is abundantly clear that slapping an attribute on any problem that comes up only create a combinatorial explosion in the language that is fundamentally unsustainable.

In the end, because these tend to contradict, the language cannot provide any guarantee one can rely on.