From 11ba77ebc2cd02865c2927b34d8b9721691f171c Mon Sep 17 00:00:00 2001 From: skyline131313 <11180237+skyline131313@users.noreply.github.com> Date: Wed, 15 Jun 2022 10:24:49 -0400 Subject: [PATCH 1/3] Add Dip1044, safe by default v2 --- DIPs/DIP1044.md | 102 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 DIPs/DIP1044.md diff --git a/DIPs/DIP1044.md b/DIPs/DIP1044.md new file mode 100644 index 000000000..a0abe958e --- /dev/null +++ b/DIPs/DIP1044.md @@ -0,0 +1,102 @@ +# Make @safe the Default v2 + +| Field | Value | +|-----------------|-----------------------------------------------------------------| +| DIP: | | +| Review Count: | | +| Author: | Walter Bright walter@digitalmars.com / skyline131313 | +| Implementation: | https://github.com/dlang/dmd/pull/10709 | +| Status: | | + +## Abstract + +Currently, D functions default to being `@system`. This DIP proposes changing the default to `@safe`. + + +## Contents +* [Rationale](#rationale) +* [Prior Work](#prior-work) +* [Description](#description) +* [Breaking Changes and Deprecations](#breaking-changes-and-deprecations) +* [Reference](#reference) +* [Copyright & License](#copyright--license) + +## Rationale + +When D was first developed, there was little interest in the extra safety checks +introduced by `@safe`. But as the costs of unsafe code have become ever more apparent +and expensive, and `@safe` has grown more capable, the balance has shifted. Users expect +safety to be opt-out, not opt-in. + +Most code should be naturally safe, and system code should be relatively rare. It makes +sense that the common case - safe code - should be the default and not require an +annotation. + + +## Prior Work + +* Other languages such as Rust and C# have safety as opt-out, rather than opt-in. +* A previous draft proposal: [@safe-by-default First Draft](https://github.com/dlang/DIPs/pull/153) +* [DIP1028](https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1028.md) + +## Description + +Functions such as template functions, nested functions, and lambdas that are not annotated +currently have their `@safe` / `@system` attribute inferred. This behavior will not change. +Other unannotated functions will now be assumed to be `@safe` rather than `@system`. + +Because this is expected to break a lot of existing code, it will be enabled with the +compiler switch: + +``` +-preview=safedefault +``` + +There are no grammar changes. + +### Non-Virtual Templated Functions + +Non-virtual function templates get their attributes inferred if they are not explicitly marked. +Hence, this proposal should not affect them. + +## Breaking Changes and Deprecations + +This will likely break most code that has not already been annotated with `@safe`, +`@trusted`, or `@system`. Annotate functions that aren't safe with `@system`. +Once the project compiles again successfully, start with the leaves marked `@system` and +modify as required to make them `@safe`. + +In general, `@system` should not be applied to blocks of functions. It should be added +specifically to each function that requires it. + +### Extern C and C++ Functions + +An unmarked `extern (D)` function will now be considered `@safe`. If its implementation is not recompiled, +it will no longer link because the mangling will be different. But for `extern (C)` and `(C++)` functions, +safety is not part of the mangling and it will compile and link without error. This has always +relied on the user getting it correct. + +Interfaces to extern C and C++ functions should always be explicitly marked. + +Any unmarked `extern` C and C++ functions will remain `@system`. + +### 3rd Party Libraries + +It's best practice for 3rd party libraries to use explicit safety annotations and not rely on defaults. +It is also best practice to compile those libraries with the same compiler that is being used +to compile the project. + +### Virtual Functions (Covariance) + +An `@safe` function can override an `@system` function, but not vice-versa. Hence, with `@safe` being +the default, the user may see compile errors when overriding a now-default `@safe` function with +a `@system` one. The user will have to decide which the inheritance hierarchy should be and annotate +as required. + +## Reference + +## Copyright & License +Copyright (c) 2019 by the D Language Foundation + +Licensed under [Creative Commons Zero 1.0](https://creativecommons.org/publicdomain/zero/1.0/legalcode.txt) + From ad79415144701afaede1b6bbbda330c3fb340f47 Mon Sep 17 00:00:00 2001 From: skyline131313 <11180237+skyline131313@users.noreply.github.com> Date: Sun, 19 Jun 2022 08:27:13 -0400 Subject: [PATCH 2/3] Add name and contact info. --- DIPs/DIP1044.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DIPs/DIP1044.md b/DIPs/DIP1044.md index a0abe958e..9da3c4c91 100644 --- a/DIPs/DIP1044.md +++ b/DIPs/DIP1044.md @@ -4,7 +4,7 @@ |-----------------|-----------------------------------------------------------------| | DIP: | | | Review Count: | | -| Author: | Walter Bright walter@digitalmars.com / skyline131313 | +| Author: | Walter Bright walter@digitalmars.com / [Mark](markleaf131313@gmail.com) | | Implementation: | https://github.com/dlang/dmd/pull/10709 | | Status: | | From fce491181be96acca1b77badbca10c22c42d86a7 Mon Sep 17 00:00:00 2001 From: skyline131313 <11180237+skyline131313@users.noreply.github.com> Date: Tue, 21 Jun 2022 10:37:34 -0400 Subject: [PATCH 3/3] Clarify declaration details. --- DIPs/DIP1044.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/DIPs/DIP1044.md b/DIPs/DIP1044.md index 9da3c4c91..82935927b 100644 --- a/DIPs/DIP1044.md +++ b/DIPs/DIP1044.md @@ -76,9 +76,7 @@ it will no longer link because the mangling will be different. But for `extern ( safety is not part of the mangling and it will compile and link without error. This has always relied on the user getting it correct. -Interfaces to extern C and C++ functions should always be explicitly marked. - -Any unmarked `extern` C and C++ functions will remain `@system`. +Any unmarked `extern` C and C++ declarations will remain `@system`. C and C++ functions with bodies will be @safe by default. ### 3rd Party Libraries