D not considered memory safe
Quirin Schroll
qs.il.paperinik at gmail.com
Mon Jul 22 13:46:34 UTC 2024
On Tuesday, 9 July 2024 at 15:53:04 UTC, Nick Treleaven wrote:
> That wouldn't be reliable and wouldn't allow safe/unsafe code
> to interact. We need the code to state what its default is.
A good first step is if a module could state its default. IMO,
this makes the most sense. The next edition should have `@safe`
by default and experts(!) can undo that changing their
new-edition modules’ default back to `@system` when it makes
sense. Writing system code is an expert activity. D shouldn’t bar
experts from their tools, just not expose anyone to them asking
for them.
The default should, essentially, be maximal safety. This doesn’t
mean you can’t disable those checks, but you have to specifically
ask for it.
It means `scope` plus extra things. `scope` makes strong
guarantees and thus is very useful for avoiding unnecessary
allocations. In `@safe` code, incorrect use will be diagnosed. In
`@system` code, `scope` is not checked, but nonetheless makes all
the guarantees. `in` (with the preview) is even worse because it
means `scope`, but also looks innocuous. You need expert
knowledge to get it right. `scope` stands out a little more,
fortunately, but `in`? “Oh, this is an input parameter, of course
let’s mark it with `in` to enable some optimizations, that’s what
it’s for.” Right, or easily corrupt memory if you don’t also use
`@safe`.
```d
// compile with -preview=in -preview=dip1000
import std.stdio;
const(int)[] global;
void f(in int[] xs) { global = xs; }
void g() { f([1,2,3]); }
void main()
{
g();
writeln(global); // (random garbage)
}
```
Maybe this is just a fluke but to me it feels `@system` code is
getting more dangerous and more expert-only over time.
More information about the Digitalmars-d
mailing list