September 23
On 9/23/2024 6:50 AM, Lance Bachmeier wrote:
> I agree. I'd actually go a bit further and say that if it's turned on by default, if anything, the effect would be to give users a false sense of security - they'd be confused why checks here and there are missing (I certainly wouldn't understand the reasoning).


Consider:
```
int* foo(int i)
{
    return &i;
}
```
which gives an error today by default. I don't think this is confusing.
September 23

On Monday, 23 September 2024 at 15:49:28 UTC, Walter Bright wrote:

>

On 9/23/2024 6:50 AM, Lance Bachmeier wrote:

>

I agree. I'd actually go a bit further and say that if it's turned on by default, if anything, the effect would be to give users a false sense of security - they'd be confused why checks here and there are missing (I certainly wouldn't understand the reasoning).

Consider:

int* foo(int i)
{
    return &i;
}

which gives an error today by default. I don't think this is confusing.

It's not that the individual checks are confusing. It's the opposite. The confusing part would be the cases that aren't being checked. There would be no reason for someone new to the language to know that they're getting a set of "almost safe" checks on their program. I can't imagine implementing something like this without making it opt-in.

September 23
On 9/23/2024 11:34 AM, Lance Bachmeier wrote:
> There would be no reason for someone new to the language to know that they're getting a set of "almost safe" checks on their program.

They get that now. There are plenty of checks already.

September 24
On Monday, 23 September 2024 at 09:02:28 UTC, Walter Bright wrote:
>

Unironically why not just grab diffs from opend?
September 24

On Monday, 23 September 2024 at 13:13:24 UTC, Walter Bright wrote:

>

a.ptr is an array overflow issue, not a pointer validation issue, as one can have an array of 0 length.

Maybe Expression.ptr can be @safe if the compiler can statically prove that Expression has non-zero length or is a string literal (which is always zero-terminated).

September 24

On Tuesday, 24 September 2024 at 19:23:57 UTC, Quirin Schroll wrote:

>

Maybe Expression.ptr can be @safe if the compiler can statically prove that Expression has non-zero length or is a string literal (which is always zero-terminated).

I implemented that but we need a good rationale to allow that.
https://github.com/dlang/dmd/pull/15581#issuecomment-1709928886

September 25
On 9/24/2024 12:23 PM, Quirin Schroll wrote:
> Maybe `Expression.ptr` can be `@safe` if the compiler can statically prove that `Expression` has non-zero length or is a string literal (which is always zero-terminated).

Unfortunately, the cases where it can statically prove this are rare. But it does what it can:
```
int foo(int i)
{
    int[3] a;
    return a[3];
}
```
```
test.d(5): Error: array index 3 is out of bounds `a[0 .. 3]`
```
October 04

On Tuesday, 24 September 2024 at 19:23:57 UTC, Quirin Schroll wrote:

>

Maybe Expression.ptr can be @safe if the compiler can statically prove that Expression has non-zero length or is a string literal (which is always zero-terminated).

I don't think that's a good idea.

First off, it makes it implementation-defined if a particular piece of code complies. When you have someString.ptr, It might be that compiler A figures out someString is never "", but compiler B doesn't. Therefore, A will accept it in a @safe function, B won't. Worse, if the function has attribute auto-inference, A and B will infer different attributes for the function, leading to confusing breakage when switching compilers.

Second, you can work around this by writing &Expression[0]. If the compiler could figure out that Expression.ptr would be safe, it can just as well figure out that bounds checks for &Expression[0] aren't needed.

October 04

On Friday, 4 October 2024 at 09:44:33 UTC, Dukc wrote:

>

It might be that compiler A figures out someString is never ""

Actually "" would be safe if string literals are zero-terminated as in DMD. Should probably have written new string(0) or something.

October 04

On Monday, 23 September 2024 at 09:02:28 UTC, Walter Bright wrote:

>

https://github.com/WalterBright/documents/blob/38f0a846726b571f8108f6e63e5e217b91421c86/safer.md

The idea that @trusted functions will get the same checks as default functions is not a good idea. Take a member function of a custom array, for instance:

// Currently:
@trusted pure nothrow @nogc opIndex(size_t index)
{   if(index >= length) assert(0);
    return ptr[index];
}

// With this DIP, it has to be:
@trusted pure nothrow @nogc opIndex(size_t index)
{   if(index >= length) assert(0);
    return (() @system => ptr[index])();
}

It's going to be a LOT of work to convert all @trusted functions to be like this.

You could argue it helps the reviewer, as the system code is highlighted by these @system lambdas. Alas, this would be of minimal use. Spotting language-defined unsafe operations, like pointer arithmetic and casts of unsafe values, is relatively easy. What is harder is spotting calls to @system functions, since those are different for each codebase and can't be memoized unlike language rules.

The proposed rule would help with the easy part but not the hard one. So please, leave rules for @trusted functions as they are now.

In the "Prior work", mention OpenD. It already has a kind of "safer by default" which is actually (not far off from what this DIP suggests)[https://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_03_25.html].

Overall... well I'm not sure. Sure, this DIP would improve safety over the present status quo, assuming @trusted rules aren't changed. But since we have editions, can't we just do a real @safe by default? We could make @safe external C functions forbidden - they would have to be @system or @trusted. That would avoid the question whether external C functions should be exempt from the change.