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