Transition to @safe by default

Quirin Schroll qs.il.paperinik at gmail.com
Tue Aug 13 15:44:45 UTC 2024


On Monday, 12 August 2024 at 18:47:02 UTC, Mike Shah wrote:
> 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.

Best one yet:

extern(C) int f() @trusted("Implementation is marked @safe");


More information about the dip.ideas mailing list