It would help to expand on the details of -msoff and -msinfo.

Walter Bright kirjoitti 29.7.2024 klo 20.23:
> To clarify, this will not change attribute inference.

You mean that if auto-inference is on, it'll work as before, instead of complaining you're calling `@system` code, right? Makes sense.

However, from your first post:
> 3. calling unattributed functions will not affect attribute inference 

Do you mean an auto-inferred function is still going to be inferred as `@safe`, not unattributed, if it calls unattributed functions but not `@system` functions? I suspect this would be met with opposition that I'd symphatise with, because of this:

```D
// unattributed
extern(c) void free(void*);

// inferred as @safe!
auto foo() => free(new int);
```

On 30/07/2024 5:16 PM, IchorDev wrote:
> P.S. `@unknownsafety` is SO long. Maybe it should be something like `@inferred`?

It would be the default, so length doesn't matter.

Although on that note I am thinking ``@infer(safe)`` would be better, since that essentially what it is doing.

On 30/07/2024 5:11 PM, IchorDev wrote:
> On Monday, 29 July 2024 at 18:23:37 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> https://gist.github.com/rikkimax/37cc5db5f381a9adc1dde6a9bbcad46d
> 
> I’m really liking this idea, I think this is very close to something I’d be fine with. I do have one reservation though:
> 
> Even people who want all of their code to be `@safe` (which includes myself) often need to use C libraries. Even if you check whole libraries to mark functions as `@trusted`, there are libraries like OpenGL which require using `__gshared` function pointers.
> Riki’s DIP appears to address this by (correct me if I’m wrong) making it so that these external C functions, when unmarked, can be called by unmarked D code. The issue is, unmarked code can be upgraded to `@safe`. I think this upgrade process should not happen if a function calls an unmarked function with no body. In fact, I suggest we make body-less functions `@system` by default.

Yes, I didn't state this but this is how I've always thought as it is based upon what the compiler can prove.

On Monday, 29 July 2024 at 16:40:52 UTC, Walter Bright wrote:
> Function safety is actually in 4 states:
>
> 1. unattributed
> 2. @safe
> 3. @trusted
> 4. @system
>
> So I propose "safe by default" to mean, for unattributed functions:
>
> 1. do all safety checks *except* checking for calling unattributed functions.

And error if an unattributed function does a non-call unsafe operation?

> 2. calling @system functions in unattributed functions will be flagged

As an error?

Then calling any unattributed function from an unattributed function must also be memory-safe, right? So how would unattributed be any more permissive than @safe?

On 7/29/24 18:40, Walter Bright wrote:
> 
> So I propose "safe by default" to mean, for unattributed functions:
> ...
Thanks for looking into this kind of thing!

> 1. do all safety checks *except* checking for calling unattributed functions.
> 
> 2. calling @system functions in unattributed functions will be flagged
> 
> 3. calling unattributed functions will not affect attribute inference
> 
> ----
> This will not make the code safe by default. But it will make code a lot safer by default,

What is a characterization of those unattributed functions that are the root cause for any lack of memory safety in unattributed functions? Is it just `extern(C)` function prototypes? If so, that seems a bit weird.

> and will provide a transition path. Code passing this will be a lot easier to transition to full safety.
I think this is getting somewhere, but probably needs something more to become really practical. Some issues I see:

- calling a single `@system` function in an unattributed one would disable other safety checks in that unattributed function as it would then infer `@system`. It seems this would likely also lead to cases where safety checks are enabled in one part of a inferreed-`@system` function, but not another part.

- there is still no way to enable safety checks in `@trusted` functions.

On 7/30/2024 12:19 PM, Richard (Rikki) Andrew Cattermole via dip.ideas wrote:

(this isn't directed at anyone in particular, and definitely not Richard, just happens to be who wrote the below quote this time)

> Yes, I didn't state this but this is how I've always thought as it is based upon what the compiler can prove.

It hasn't come up in a long time, so this is a reasonable time to remind everyone that the compiler doesn't prove @safe-ty.  It checks for not-@safe-ty.  The logic is backwards from what it 'should' be, imho. Instead of only allowing known to be safe code, it blocks known to be problematic code.  Meaning that omissions in the logic default to open rather than closed.

Assuming perfect no-bugs code, the distinction doesn't matter.  But no complex system is perfect.  Fixing that part of the implementation might make for a great summer of code project for some eager student.

Later,
Brad

On Monday, 29 July 2024 at 16:40:52 UTC, Walter Bright wrote:
> As discussed in this thread:
>
> https://www.digitalmars.com/d/archives/digitalmars/D/D_not_considered_memory_safe_374866.html
>
> [...]

I liked the Walter idea.