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