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