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

All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.

Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

*Please stay on topic!*

Thanks in advance to all who participate.

On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":

And to make it searchable: #DIP1028

On Thursday, 2 January 2020 at 09:47:48 UTC, 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
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

This is a simple but really powerful change. I think most issues you would have with @safe right now would simply be gone as it's very often libraries which are not marked @safe causing trouble, rather than actually using unsafe code.

In my experience most code is written as safe code and only very rarely are the unsafe code features actually needed. Having aid by the compiler not accidentally using unsafe code will definitely help most users. Users writing a lot of @system code like for example those writing OS drivers (very niche) will have issues that relatively easily can be fixed by placing @system in the affected functions or add a @system: on top of the file (which will not work that well with the other code though)

As with all such changes there will be a lot of pain and silent breakage for those using __traits(compiles, {}) with something related with @safe/@system. I don't think deprecations are shown in it so the transition period will also not help with that. I think having a system to mitigate this issue is really important, but that's rather part of another DIP and shouldn't interfere so much with this DIP. With these 'compiles' checks for @safe/@system you most often call the function anyway, which will trigger the deprecation warnings so this is not that big of an issue in 98% of the cases.

To fix code it will be minimal changes, which could probably even be automated by suggestions from the IDE. :)

Overall I think the DIP is good as-is and will bring more positives than negatives to D.

On Thursday, 2 January 2020 at 09:47:48 UTC, 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
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

While I don't disapprove I suggest a very long deprecation phase, based on

1. a compiler switch for let's say 1 year, allowing to test and prepare
2. after that, the real deprecation, following what the official rule for D deprecation imply, and concerning what is not annotated
3. after that, non annotated funcs will be @safe.
4. Maybe a compiler switch for backward compatibility should be added at the end. This could help in case someone use unmaintained libraries.

Based on this comment, I suggest to amend the DIP to add a **very detailed plan**, a schedule, for how things would append. This is not clear for now.

Finally a more technical remark is that maybe you should mention that annotating a whole module, after the module declaration, `@system:` makes the maintenance easy. For now the DIPS seems to suggest that all funcs should be annotated.

On Thursday, 2 January 2020 at 09:47:48 UTC, 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
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

"This will likely break most code that has not already been annotated with @safe, @trusted, or @system. Fortunately, the solution is easy, although tedious: annotate functions that aren't safe with @trusted or @system."

Maybe I'm missing something, but the spec says

"Trusted functions are guaranteed to not exhibit any undefined behavior if called by a safe function. Furthermore, calls to trusted functions cannot lead to undefined behavior in @safe code that is executed afterwards. It is the responsibility of the programmer to ensure that these guarantees are upheld."

If I want to make my code compile, I'd be forced to declare a function @trusted *even if it shouldn't be*. In other words, if we go down this road, @trusted loses its meaning. If I mark it @system, that doesn't really help, because my code still isn't going to compile.

Perhaps someone can explain where I'm wrong. If I'm correct, then it would make more sense to declare at the top of a file that this is legacy code and thus treated as @trusted unless marked otherwise.

On Thursday, 2 January 2020 at 11:10:38 UTC, bachmeier wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, 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
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>>
>> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>>
>> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>>
>> *Please stay on topic!*
>>
>> Thanks in advance to all who participate.
>
> "This will likely break most code that has not already been annotated with @safe, @trusted, or @system. Fortunately, the solution is easy, although tedious: annotate functions that aren't safe with @trusted or @system."
>
> Maybe I'm missing something, but the spec says
>
> "Trusted functions are guaranteed to not exhibit any undefined behavior if called by a safe function. Furthermore, calls to trusted functions cannot lead to undefined behavior in @safe code that is executed afterwards. It is the responsibility of the programmer to ensure that these guarantees are upheld."
>
> If I want to make my code compile, I'd be forced to declare a function @trusted *even if it shouldn't be*. In other words, if we go down this road, @trusted loses its meaning. If I mark it @system, that doesn't really help, because my code still isn't going to compile.
>
> Perhaps someone can explain where I'm wrong. If I'm correct, then it would make more sense to declare at the top of a file that this is legacy code and thus treated as @trusted unless marked otherwise.

I want to make this comment in a new reply since it's separate from the previous comment. I dislike this proposal because it's too large without a corresponding move to D 3.0. It won't just break existing code, but also existing tutorials and documentation. I strongly support the change. Just not in D 2.* since that will be too confusing for new/occasional users of the language.

On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>

I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type, 2) someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).

On Thursday, 2 January 2020 at 11:19:52 UTC, jmh530 wrote:
> On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>>
>
> I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type, 2) someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).

If a function is not annotated, why should it default to @system? That has a specific meaning that probably shouldn't apply to most code.

On Thursday, 2 January 2020 at 11:31:59 UTC, bachmeier wrote:
> [snip]
>> I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type, 2) someone writes a tool that adds @system to every function that is not annotated @safe or @trusted (or already @system) (probably not that hard).
>
> If a function is not annotated, why should it default to @system? That has a specific meaning that probably shouldn't apply to most code.

I'm thinking about the transition. (non-template) Functions are currently implicitly @system, but that will change to @safe. So there should be a way to easily transition from the old default to the new one. Not really different from what someone mentioned above with putting @system: at the top of the file.

On 02.01.20 12:10, bachmeier wrote:
> If I want to make my code compile, I'd be forced to declare a function @trusted *even if it shouldn't be*. In other words, if we go down this road, @trusted loses its meaning. If I mark it @system, that doesn't really help, because my code still isn't going to compile.

Yes, you shouldn't blindly slap @trusted on your non-@safe functions.

But you *can* blindly slap @system on them. Non-annotated functions are already @system by default; you're just making it explicit. Your code should compile the same as today.

> Perhaps someone can explain where I'm wrong. If I'm correct, then it would make more sense to declare at the top of a file that this is legacy code and thus treated as @trusted unless marked otherwise.

There's not really a way to do it for a whole file, but with `@system:` and `@system { ... }` the busywork might be tolerable. Though I would consider it better practice to mark each function individually.

And legacy code should be treated as @system, not as @trusted.