DIP 1028---Make @safe the Default---Community Review Round 1

[Dennis]

On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md

> # Rationale

The rationale is short and makes claims without any motivation, 
such as:

> the costs of unsafe code have become ever more apparent and 
> expensive

> Users expect safety to be opt-out, not opt-in

It doesn't answer questions such as:
- how many D users actually prefer @safe by default, and how many 
prefer @system?
- how many memory corruption bugs actually happen in D code that 
is @system, and how many in code that is @safe?
- how much existing D code can be marked @safe but currently 
isn't?

Consequently the DIP does not give the reader enough information 
to judge whether this is a good idea.

The DIP author guidelines state:
> It is vital to research any alternative approaches to solving 
> the same problem and explain why the proposed choice is 
> superior.

There currently is no mention of any alternatives however. Some 
things that can be considered:

- A linting tool that automatically inserts `@safe` annotations 
where possible. Any time a D library can be marked `@safe` but 
the author forgot to annotate functions with `@safe`, a Pull 
Request can easily be made adding the missing annotations.
- Adding an option to specify @safe/@system by default in code, 
such as `@safe module foo;` or `@system module foo;`. Note that 
this is not the same as putting `@safe:` or `@system:` on top, 
since:

```
@system:
auto canBeSafe() {} // is @system, would be @safe without the 
above `@system:`
struct S {
     void memberFunc(); // unaffected by module-level annotation
}
```

These options don't have the code breakage that the proposed 
solution has, while arguably solving most of the same issues. 
Interestingly, 3.5 years ago you said @safe by default would 
break too much code and adding `@safe:` on top of a module is 
very doable:

https://forum.dlang.org/post/nj73gp$1q3k$1@digitalmars.com

It makes me wonder why @safe becoming the default is deemed 
necessary now. What changed?

> # Breaking Changes and Deprecations

The DIP doesn't mention how functions without a body will 
implicitly become `@trusted`.
```
import std;
extern(C) size_t strlen(const(char)*); // @safe by default

void main() {
     strlen(new char).writeln; // this now passes as @safe
}
```

> Functions such as template functions, nested functions, and 
> lambdas that are not annotated currently have their @safe / 
> @system attribute inferred.

Functions with return type `auto` also have attributes inferred. 
I think they should be mentioned in there too, unless you want 
functions with `auto` return type to always be assumed @safe:

> Any other unannotated function that will now be assumed to be 
> @safe rather than @system.