On 13.02.22 12:15, 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?

Roughly, that's what @safe is supposed to be, yes. But it's not quite as simple because `main` isn't the only possible entry point, and because @trusted exists.

> What about data races in updates of multi-word variables?

As far as I know, this is D's current approach:

All shared data must be marked with `shared`. @safe code cannot access `shared` data (only enforced with `-preview=nosharedaccess`). If you want to mess with `shared` data, you need to write @system/@trusted code and ensure thread safety yourself.

Since you mentioned it in the topic, note that DIP 1000 doesn't make @safe safer. It allows some formerly @system code to become @safe. If you write that kind of code, DIP 1000 is nice to have. If you don't, DIP 1000 doesn't affect you.

On 13.02.22 13:37, Florian Weimer wrote:
> Hmm.  This compiles without `-dip1000` (or `-ftransition=dip1000`), but is unsafe:
> 
> ```d
> int[] global;
> 
> @safe
> void f0(int[] val) {
>      global = val;
> }
> 
> @safe
> void f1() {
>    int[3] local = [1, 2, 3];
>    f0(local);
> }
> 
> ```
> 
> It's rejected in DIP 1000 mode (both by DMD and GDC).

Yeah, bugs are plenty. And if a bug doesn't manifest with `-preview=dip1000`, then people are even less likely than usual to give a damn about it. Because DIP 1000 is going to become the default eventually, and then the issue will go away anyway.

It goes the other way, too: `-preview=dip1000` has safety holes that aren't there without the switch. But those are more likely to get fixed, because some people do care about getting DIP 1000 done.

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.


> What about data races in updates of multi-word variables? For example, the Go language makes avoiding them the responsibility of the programmer, but Java ensures that data races cannot subvert the type system (although with the demise of the security manager, some people argue that this should be changed).

It's up to the programmer to avoid data races in multi-word variables, likely by manually using locks.

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.

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.

On Mon, Feb 14, 2022 at 01:15:26PM +0000, Paul Backus via Digitalmars-d wrote:
> On Monday, 14 February 2022 at 08:39:58 UTC, Walter Bright wrote:
[...]
> > 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.

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


T

-- 
Once the bikeshed is up for painting, the rainbow won't suffice. -- Andrei Alexandrescu

On Monday, 14 February 2022 at 15:50:31 UTC, H. S. Teoh wrote:
> On Mon, Feb 14, 2022 at 01:15:26PM +0000, Paul Backus via Digitalmars-d wrote:
>> On Monday, 14 February 2022 at 08:39:58 UTC, Walter Bright wrote:
> [...]
>> > 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.
>
> The problem with @safe as it is implemented today is that it's implemented as a blacklist rather than a whitelist.

I did say "should be" and "modulo compiler bugs" for a reason. :)

Even with a whitelist implementation, though, we'd still have bugs where something was accidentally whitelisted that shouldn't have been. Several of the recent fixes to -preview=dip1000 are for exactly this type of bug, for example.

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.

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.