Safer D first draft (page 2)

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.

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.

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]` ```

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

Re: Safer D first draft

Posted by Dukc
in reply to Walter Bright

Permalink

Dukc

Posted in reply to Walter Bright

Permalink

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.

Forums