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