On Friday, 3 January 2020 at 07:40:14 UTC, H. S. Teoh wrote:
>
> Another issue is that taking the address of locals is verboten in @safe code.

You can actually use DIP1000 to allow this. That's why it would be great to have a fully-working '@safe' before making it the default.

On 2020-01-02 10:47, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
> 
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md 

With a DIP causing this large breakage I expect the DIP to be accompanied with a tool that will do the following automatically:

* Annotate the source code to retain the current semantics, i.e. basically annotate all non-inferred functions with @system

* Annotate all non-inferred functions in the source code with @safe where it would compile

-- 
/Jacob Carlborg

On 1/2/2020 6:00 PM, 12345swordy wrote:
> Done,
> https://issues.dlang.org/show_bug.cgi?id=15246

Thank you.

On 1/2/2020 6:42 PM, 12345swordy wrote:
> What about bugs for @safe that require an DIP to fix then? Your dip doesn't address this at all.

Because this DIP is about making @safe the default, not changing the behavior of @safe.

> Your strategy seems to make it safe by default and not worry about any code that may be broken from using unsafe language features that can not be simply fix with a pull request. I don't see how this is in any way off-topic here. Is your current workaround for this is to abused the @trusted feature?

I don't really understand what the problem is. Making code @safe by default will not cause code to regress into bugginess. What it will do is necessitate labeling code with @system that were always @system already.

On 1/2/2020 10:31 PM, Mathias Lang wrote:
> On paper, this sounds like a great idea. Make '@safe' the default so people have to opt out of memory safety rather than opt-in. However, we have extensive experience with those changes (and how they are handled), and I am not, as it stands, in favor of it.

Modules can be labeled as @system by beginning them with:

   @system:


> First, because '@safe', and attributes by extension, is currently not a practical tool, and even not usable in some cases.

Issues not in bugzilla do not get fixed. Please add issues that make it not practical or usable to bugzilla and mark them with the `safe` keyword.


> It is currently painful to mix differently-attributed code if you are not going full template (e.g. classes, delegates). I've worked for two companies using D, and none of them used @safe, and were more on the low-level side of things.

It is true that using @safe successfully will often entail some level of refactoring to separate the safe code from unsafe code. It is perfectly fine if you choose to not use @safe.


> In fact, @safe wouldn't even have prevented most of the bug we had,

Most is not all, and the bugs it does uncover tend to be the ugly ones. I recently spent 3 days trying to track down a memory corruption bug in DMD. These are not happy hours for me. Detecting problems at compile time is infinitely cheaper.

It's also the future. It's clear where languages are going. Unsafe languages are going on the ash heap of history. We can either get in front of this sea change, or get run over by it.


> Second because those kind of changes have historically been badly handled, as the impact is not fully assessed. For such a large and impactful change, I would expect the proposer of the DIP to assess the impact of this change on a few projects, in order to provide a data point. Either go with major D projects, and/or pull a sample for the dub registry, to gauge the hassle, performance and readability degradation it can bring.
> Yet DMD is not @safe. Neither is druntime. DUB, Vibe.d ? Neither. And I've seen countless places where '@safe' is either forced on the user (by forcing the user to provide '@safe' routines), or just bypassed by means of '@trusted'. Just take a look at Vibe.d.

The simplest way to be compatible with the switch is to simply label things that don't compile as @system. Or just put @system: at the beginning.

As for DMD, I intend to take advantage of this feature as soon as it is accepted. Keep in mind that DMD was originally a "C with Classes" program, with no notion of @safe (or const, pure, nothrow, or nogc).


> Side note, using this flag to compile Phobos would most likely result in link failures, like it did with DIP1000.

We fixed the link failures with DIP1000.


> Third, we start to have a few DIPs piling up in the -preview section. DIP25, DIP1000, DIP1008. Some libraries use it, some don't, and adding more features there will only balkanize the language more.

All programming languages improve or die.


> actually finish what we started.

All issues need to go into bugzilla. Issues not in bugzilla do not get fixed.


> TL;DR: Disruptive change that requires every D user to put some work to support it (possibly many months worth of work), yet no evidence that a single large-scale project have been experimented with while writing this DIP.

Nobody will try it, either, unless and until it is actually put into the compiler.

On 1/3/2020 12:59 AM, Jacob Carlborg wrote:
> With a DIP causing this large breakage I expect the DIP to be accompanied with a tool that will do the following automatically:
> 
> * Annotate the source code to retain the current semantics, i.e. basically annotate all non-inferred functions with @system
> 
> * Annotate all non-inferred functions in the source code with @safe where it would compile

Such a tool would indeed be welcome. Please write it! (Perhaps modify dfix?)

On 1/2/2020 10:14 PM, Jesse Phillips wrote:
> I would part of the rational would be: A large portion of functions should find themselves performing safe operations. Leaving off prevents the use of safe functions which were not evaluated for safety (safe functions remain usable in system functions).
> 
> This would be the same rational to apply nothrow by default. Though it may not have the same qualities of benefits.

There's another DIP coming that will make nothrow the default. Please, anyone replying to this, start another thread for it.

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.

On 1/2/2020 6:11 PM, Timon Gehr wrote:
> On 03.01.20 02:31, Walter Bright wrote:
>> On 1/2/2020 9:27 AM, Arine wrote:
>>> If you could annotate the module with @system to use the old behavior, this will ease the transition period. This is better than simply having a compiler flag that changes behavior, as you can see in the code that is using the old behavior. You can also disable it per module, not either on or off for everything.
>>>
>>>      @system module std.stdio; // or similar
>>
>> We already have that in starting a module with:
>>
>>      @system:
>>
> 
> This will not result in the old behavior. It will disable inference of @safe in that module.

Ah, you're right for template code.

On 1/2/2020 9:20 PM, Arine wrote:
> On Friday, 3 January 2020 at 01:31:26 UTC, Walter Bright wrote:
>> This DIP is not about changing how trusted code is inserted. If you'd like to discuss that, please start a separate thread. Please keep this thread on-topic about the DIP.
> 
> If issues with @safe aren't going to be considered with this DIP, then I'd say this DIP should be delayed until issues with @safe are resolved before forcing it as the default.

No. We don't have time to do all development serially.


> Don't think I can think of a language that is safe by default that needs to use a hack with a separate language feature to get desired behavior.

Issues not in bugzilla do not get fixed. Please put all issues with @safe in bugzilla and mark them with the `safe` keyword.

Then, when bringing up a problem or set of problems, link to the corresponding issues.

There's NOTHING AT ALL anyone can do with statements like "needs to use a hack" because nobody has any idea what you're referring to.