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

[Arine]

On Thursday, 9 January 2020 at 18:47:23 UTC, Johannes Pfau wrote:
> Now someone changes data to int[2]:
>
> @safe void someFunction()
> {
>     int[2] data;
>     // Lot's of code
>     @trusted
>     {
>         data.ptr[3] = 42;
>     }
> }
>
> So by modifying @safe code only, you introduced a memory safety 
> issue. The interface of a @trusted function however is more 
> strictly defined:
>
> @trusted function set(ref int[4] data)
> {
>     data.ptr[3] = 42;
> }
>

That's a pretty contrived example.

@safe void someFunction()
{
     int[2] data;
     // Lot's of code
     @unsafe
     {
         static assert( data.length > 3 );
         data.ptr[3] = 42;
     }
}

There you get the same safety and you don't have to create a 
separate function that passes in a ref to a int array of a static 
size, that'll probably literally never be used anywhere else.

If it's a dynamic array, then they are both equally @unsafe and 
it's up to you to ensure it is safe. If you have that @unsafe 
block in the function, it's going to be a lot easier to see where 
that potential problem is. Otherwise it'll look like any other 
@safe function.