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.