Permalink
Reply
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.
// 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.
