Transition to @safe by default

[Timon Gehr]

On 8/6/24 02:54, 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.

That is not what the DIP says, and I think it is a really bad idea.

> Or we 
> could simply say that prototypes would have to be explicitly attributed 
> in order to be callable from @safe code.
> ...

That was my expectation from reading the DIP. My point was however more 
that unattributed functions will be perhaps not memory safe, but the 
only way to smuggle in something that is not memory safe in practice is 
via `extern(C)` prototypes, as all other checks appear to be present.

I think it is a bit weird to require `extern(C)` prototypes for this 
case of "unsafe unannotated". It would be better to be able to disable 
and enable safety checks in a more granular fashion.

> ...
> 
>> - 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.
> ...

One can actually not always do that. Think template instantiation.

> But in general, trusted code should be a very small part of a program.

`@system` and `@trusted` code is where all the remaining memory safety 
accidents happen.

Basically, the issue is the lack of orthogonality between safety 
checking and interface safety. It does not hold that just because your 
interface is not safe, your implementation does not care about catching 
bugs. Supporting linting use cases is quite cheap, as the checks are in 
the compiler anyway.