Direction for @safe/-dip1000

Timon Gehr timon.gehr at gmx.ch
Wed Feb 16 17:15:41 UTC 2022


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.


More information about the Digitalmars-d mailing list