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

[WebFreak001]

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.