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

[bachmeier]

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.