Transition to @safe by default

Mike Shah mshah.475 at gmail.com
Mon Aug 12 18:47:02 UTC 2024


On Tuesday, 6 August 2024 at 00:54:32 UTC, Walter Bright wrote:
> On 7/30/2024 1:09 PM, Timon Gehr wrote:
>> What is a characterization of those unattributed functions 
>> that are the root cause for any lack of memory safety in 
>> unattributed functions? Is it just `extern(C)` function 
>> prototypes? If so, that seems a bit weird.
>
> Function prototypes can only be taken at face value. If they 
> are unattributed, they would be accepted as callable from @safe 
> code. Or we could simply say that prototypes would have to be 
> explicitly attributed in order to be callable from @safe code.
>
>
>> - calling a single `@system` function in an unattributed one 
>> would disable other safety checks in that unattributed 
>> function as it would then infer `@system`.
>
> Not necessarily. But it would still require the caller to mark 
> the function @trusted or @system.
>
>
>> - there is still no way to enable safety checks in `@trusted` 
>> functions.
>
> One can always switch it temporarily to @safe, fix any errors, 
> then put it back.
>
> But in general, trusted code should be a very small part of a 
> program.

One thought I had that might be an incremental improvement on 
using @trusted during refactoring is the ability to add a 
'reason' to the attribute (C++ does this for the function that 
are attributed nodiscard --[[nodiscard("some reason here")]].

e.g.

void foo() @trusted("Have not made this function safe yet, still 
refactoring")
{
     // Something not yet refactored to be safe

}

void bar() @trusted("Manually verified by code review to be safe 
on Aug. 12, 2024")
{
     Third_Party_Library_Function_With_Interface_We_Trust_or_Own();
}

@safe SafeFunction(){
   // Calling into 2 'trusted' functions
   foo();
   bar();
}

Some other notes:

- There would be no reason to add a 'reason' for @safe or @system 
code (@safe is verified by the compiler already, @system is known 
to be an 'unsafe' block of code).
- Compiler or tooling could dump out @trusted functions with an 
annotated reason (similar to 'deprecated' messages) to programmer.






More information about the dip.ideas mailing list