Direction for @safe/-dip1000

Timon Gehr timon.gehr at gmx.ch
Mon Feb 14 21:02:31 UTC 2022


On 2/14/22 14:15, 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.
> ...

Exactly, incorrect use of @trusted. @live is only useful in @trusted or 
@system code as a linting tool.

> What adding an ownership/borrowing system does (or should do)

@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.

> 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.

Yes, and that's precisely why @live is not extremely useful and 
comparisons with ownership/borrowing systems from academia are 
superficial and wildly overblown.


More information about the Digitalmars-d mailing list