Now that this has been merged into master, what are your reactions?

On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright wrote:
> Now that this has been merged into master, what are your reactions?

Brilliant, I seldom used @safe, so this is just what I needed.

On Saturday, December 14, 2024 1:46:35 AM MST Walter Bright via Digitalmars-d wrote:
> Now that this has been merged into master, what are your reactions?
>

Honestly, the more I think about it, the less I see the point in it, but I also don't see it as a problem so long as it never becomes the default.

If I want a function to be @safe, I'll mark it with @safe, and I'll get all of the appropriate checks. The fact that I didn't mark a function with @safe means that I either want it to be @system and was relying on the current default - or more likely that I didn't care about @safety at all with that piece of code (which often happens with stuff like scripts or other small programs).

I assume that the point behind the flag is to provide a tool to track down places where there would be issues when @safe becomes the default so that they can be fixed now, but if I actually want to do that, I can just start putting @safe on my functions, and there's no need for a compiler flag.

So, from what I can see, the only real use case for -preview=safer is if I want to check a bunch of code for @safe without taking the time to actually mark it with @safe under the assumption that when @safe becomes the default, those explicit attributes will be unnecessary. And maybe that's worth having the flag for (and you already implemented it regardless), but in my case, if I actually care about a particular piece of code being checked for @safe, I'm just going to take the time to mark it with @safe, and then I also get the benefit of being able to call that function from @safe code, which the flag doesn't help with.

So, I don't necessarily see any problem with the flag, but I also don't see much benefit in using it.

On the other hand, if your plan is to ever make -preview=safer the default, then I think that that's a serious problem, because it's forcing almost all of the @safe checks without actually making @safe the default. So, all of the code that fails the flag will break, and you'll _still_ have to go and mark all of the functions with @safe if you want to actually call them from @safe code. So, it's forcing almost all of the checks on everything that isn't explicitly @system (just missing the one about calling @system functions) without actually providing the full benefits. From what I can see, simply turning on @safe by default would make more sense than turning on -preview=safer as the default.

So, I have no problem with the flag as a linting tool to prepare for @safe by default, but I very much hope that it's not your intention to ever make the flag the default. And I would expect that in most cases, anyone who actually cares about @safe enough to use the flag would be using @safe explicitly anyway, but I can certaintly believe that some folks will want to use the flag to check for potential issues with @safe by default without actually taking the time to mark anything with @safe to then get the full benefits of @safe now.

- Jonathan M Davis

On Saturday, 14 December 2024 at 09:44:05 UTC, Daniel N wrote:
> On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright wrote:
>> Now that this has been merged into master, what are your reactions?
>
> Brilliant, I seldom used @safe, so this is just what I needed.

BTW: Is it intended that this code

   import std.stdio;

   @safe:

   void allocate (ref int [] a)
   {
      int [16] b;
      writeln (b);
      a = b;
   }

   void main ()
   {
      int [] c;
      allocate (c);
      writeln (c);
   }

not only requires the "@safe" but also the -dip1000 switch
in order to reject compilation:

   u.d(9): Error: address of variable `b` assigned to `a` with longer lifetime

Why does the compiler make it so difficult to enable this diagnostics?

On 14/12/2024 11:46 PM, kdevel wrote:
> Why does the compiler make it so difficult to enable this diagnostics?

We went down the enabling of it path, but it broke too much code and too few people understood it.

As a design DIP1000 is not expressing enough for it to not catch things that it shouldn't and what it does express makes it easily misunderstood.

There has been a hard line drawn for PhobosV3, it will not use it in its current form. Quite some dislike for it exists within the community.

On 12/14/24 09:46, Walter Bright wrote:
> Now that this has been merged into master, what are your reactions?

Here's what I tried. (`&x` is just a placeholder for any unsafe operation, I am aware it would be fine for this to compile here, as it would with DIP1000.)


```d
import std;

void foo()@system{}

void bar(){
    foo(); // ok
}

void baz(){
    int x;
    // auto y=&x; // error, good
}

void qux(){
    foo(); // ok
    int x;
    // auto y=&x; // error, good
}

auto bongo(){
    int x;
    auto y=&x; // ok, bad
}

void flarp()(){
    int x;
    auto y=&x; // ok, bad
}

void main(){
    writeln("hi"); // ok
}
```

So I don't know, it's mixed for me. I do like the idea of linting functions with a not necessarily safe interface using the ordinary safety checks by default.

OTOH it is not so great that inferring a return type or using a template will disable the checks. I cannot even opt in: there is no explicit way to say: neither `@safe` nor inferred `@system`. I either have to go `@safe`, which may not be an option if the function interface is not memory safe, and even if the function interface is memory safe, I will have to opt into transitivity of `@safe` at that point, which is already the existing tradeoff without `-preview=safer`.

I will probably use the flag, but I have projects where a lot of my code or, more importantly, code in its dependencies, is templated and/or infers return types. `-preview=safer` will just not do all that much there.

On 12/14/24 16:12, Timon Gehr wrote:
> On 12/14/24 09:46, Walter Bright wrote:
>> Now that this has been merged into master, what are your reactions?
> 
> ...
> 
> I will probably use the flag, but I have projects where a lot of my code or, more importantly, code in its dependencies, is templated and/or infers return types. `-preview=safer` will just not do all that much there.

Furthermore, with `-preview=safer`, there are now those combinations (MS = memory safe interface):

            | MS       | guaranteed MS | maybe not MS
------------+----------+---------------+-----------------------
checks      | ???      | @safe         | default safety
no checks   | @trusted | cannot exist  | @system


So another thing that is a bit non-orthogonal is that there is no way to have non-transitive safety checks enabled in a function whose memory safety cannot be established using compiler guarantees. I.e. you cannot have both `@trusted` and default safety checks.

On 12/14/24 09:46, Walter Bright wrote:
> Now that this has been merged into master, what are your reactions?

Another thing is that the error messages are bad: it says "cannot do X in `@safe` function `f`", even if `f` is not a `@safe` function.

On Saturday, 14 December 2024 at 08:46:35 UTC, Walter Bright wrote:
> Now that this has been merged into master, what are your reactions?

I agree with Jonathan M Davis that the behavior of this flag should never be made the default.

As I said in my response to the initial proposal [1], it has all of the costs of @safe-by-default (breaks lots of existing code) without any of the benefits (reducing attribute spam and ecosystem fragmentation). It does nothing to help D programmers who are already using @safe, and creates a new source of annoyance for people who are currently happy with @system as the default.

The easiest way to satisfy the compiler when -preview=safer is enabled is to mark all the functions it flags as explicitly @system. Because of this, I think it's unlikely that -preview=safer will achieve its stated goal of "mov[ing] such code to @safe" [2].

[1] https://forum.dlang.org/post/dkbrgvjcqsdpuvaeckty@forum.dlang.org
[2] https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md#rationale

On 12/14/2024 2:20 AM, Jonathan M Davis wrote:
> if I actually want to do that, I can just start
> putting @safe on my functions, and there's no need for a compiler flag.

We've pushed that for years, but it doesn't work. It doesn't work because of the transitive nature of @safe - you can't do it piecemeal, it has to be done all at once.

Safer is enabling the checks, but not transitively.