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