Safer D first draft

Dukc ajieskola at gmail.com
Fri Oct 4 10:34:21 UTC 2024


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:

```D
// 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.


More information about the dip.development mailing list