Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[H. S. Teoh]

On Fri, Apr 03, 2020 at 11:53:57PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> I understand your proposal. You want C functions without bodies to be
> @system.
[...]
> On the other hand, special cases like this tend to cause unexpected
> problems in the future. Experience pretty much guarantees it. It's
> likely to be tricky to implement as well.
> 
> People remember simple rules. They don't remember rules with odd
> exceptions to them, that always winds up with trouble and bug reports.
> Simple rules applied evenly lead to a compiler that works and is
> reliable.

The rule:

	extern(D) => @safe by default
	extern(C) => @system by default

hardly sounds "odd" to me.  It almost verbally describes what C is, and
what we want D to be, there's nothing easier to remember.


> I'm afraid the weight of all the special rules will crush D.

Now *that's* an odd statement, considering that you recently just posted
that memory safety by default is the way to go, and now you're proposing
to add a huge big hole to @safe, and even more ironically, this in the
name of making D code safer.

	// Current situation: user forgot to write @system on an
	// extern(C) function, the code fails to compile, the user is
	// informed of it, and makes the appropriate fix:
	extern(C) int myfunc();	// @system by default
	void main() @safe {
		myfunc();	// compile error
	}

	// Proposed situation: user forgot to write @system on an
	// extern(C) function, the code compiles beautifully, the user
	// is not informed of any potential problem, and didn't fix it
	// until it explodes in the customer's production server:
	extern(C) int myfunc();	// @safe by default, but actually @system
	void main() @safe {
		myfunc();	// no compile error, @safe is bypassed
	}

Yep, this certainly makes D all the more memory-safe, and D certainly
won't be crushed by the weight of all the newly-added @safety loopholes,
nope, not at all! :-P


[...]
> The rule is simple:
> 
> "For a D module with a bunch of C declarations in it, start it with
> `@system:`."
[...]

Since the rule is this simple, and can be mechanically automated, why is
it still left as a burden on the user to do it?  What we're proposing is
simply to make this rule mechanically enforced, instead of coding by
convention, which we all know all too well how it will end up.  Whatever
happened to mechanically-verified correctness vs. coding by convention?


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth