On Saturday, 6 July 2024 at 23:39:54 UTC, Sebastian Nibisz wrote:
>On Saturday, 6 July 2024 at 23:10:02 UTC, Walter Bright wrote:
>On 7/6/2024 4:07 AM, Sebastian Nibisz wrote:
>Seriously? Any language is safe in this case, you just need to write safe code.
Enabling the checks is quite different from writing code with no bugs in it.
But you have to remember to enable it. Inexperienced programmer usually won't do this and will build unsafe code unconsciously.
This is the single best reason to enable @safe
by default. Writing correct @system
code is as hard as writing @trusted
code, and both require the programmer to know the language very, very well. You shouldn’t mark a function @system
or @trusted
unless you understand exactly why that’s the right thing.
The only big issue with @safe
by default is higher-order functions. Because @safe
makes no guarantees (unlike pure
or nothrow
), requiring a callback delegate to be @safe
makes no sense generally. (In contrast, requiring a pure
or nothrow
callback can make sense in special circumstances. Practically, if your higher-order function can be called with a @safe
callback, it can be called with a @system
callback. The problem is that the language does not understand this.
This means, in general, higher-order functions must be overloaded:
void hof(void delegate() @system callback) @system => hof(cast(void delegate() @safe)callback);
void hof(void delegate() @safe callback) @safe
{
callback();
}
For application code, it might be fine if a callback is needlessly required to be @safe
if the application is @safe
code anyway. Libraries can’t make such assumptions on usage, though.
Top-level @safe:
does not influence callback types. In a DIP Idea, I proposed default @safe module
declarations, so that for any declaration lexically in the module, @safe
is applied by default instead of @system
.