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

[Jesse Phillips]

On Saturday, 4 January 2020 at 05:43:25 UTC, Jesse Phillips wrote:
> On Friday, 3 January 2020 at 05:57:09 UTC, Jesse Phillips 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
>>>
>>
>> I think the DIP should specify the depreciation plan. 
>> Currently it only mentions it would be available through 
>> --preview (is it not expect to go further?
>
> Another thought to depreciation, the compiler could deprecated 
> system functions which aren't marked @system.
>
> This depreciation would ignore all method calls. This basically 
> means functions utilizing unsafe language features must declare 
> that use in the signature.
>
> The next part I'll need to think on is if there is a way to 
> build out the @trusted annotations.

With the above rule in place and taking precedence, the next 
depreciation would be that unmarked methods could not call into 
@system methods. This would cause a chain effect until a method 
was marked trusted or the marking of @system was added to main.

There was an effort to show projects build state if safe was 
default. These depreciations should have no ill effect on 
building projects as they will not have unmarked system code.


One of the main benefits here is that it creates a resolution 
from the bottom up instead of the top down. If @safe were just 
made default then resolution for what code is trusted would 
likely favor higher in the call chain will this depreciation 
approach encourages creation of a trusted interface quickly.