Safety, undefined behavior, @safe, @trusted

[bearophile]

Walter Bright:

> Following the safe D discussions,

I was busy, I am sorry, I have not followed it, but I have read part of the PDF of Cardelli shown by Andrei.


> Based on Andrei's and Cardelli's ideas, I propose that Safe D be defined 
> as the subset of D that guarantees no undefined behavior.

I am asking for this for a lot of time, because SafeD meant MemorySafeD so far.
So D is again converging toward something similar to what C# has chosen long time ago. Maybe it's time to look better at C#.


> Safety seems more and more to be a characteristic of a function, rather 
> than a module or command line switch.

In C# you use something like:

unsafe {
  // lot of code
}

I think that's a good solution. Things are meant as safe unless marked as unsafe. You can mark a whole block of code as unsafe putting it into those brackets. D may do the same. Also single functions may have the @unsafe attribute.


> To mark an entire module as safe, add the line:
> 
>     @safe:
> 
> after the module statement. Ditto for marking the whole module as 
> @trusted.

Why is this not good?
module foo(unsafe);
(But the unsafe {...} may be enough for a whole module too).


> An entire application can be checked for safety by making 
> main() safe:
> 
>      @safe int main() { ... }
> 
> This proposal eliminates the need for command line switches, and 
> versioning based on safety.

I may have missed some important parts of the discussion, but this test seems fit for a command line switch (C#uses one for this purpose. If your program has one or more unsafe parts, it needs an unsafe comment line switch. I agree it's a tool a little blunt).

Bye,
bearophile