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

[Johannes Pfau]

Am Thu, 09 Jan 2020 10:12:23 +1000 schrieb Manu:

> 
> unsafe blocks is distinctly preferable to me. Functions are usually >1
> line, and I hate that we can only mark this at the function level.
> Unsafely statements are never at the function level, it's usually just
> one line among a larger function. An unsafe scope would be immensely
> preferable to me, because I can make it as narrow as the code i'm
> suspicious of, and the surrounding code doesn't lose its safe checking
> just by being a bystander.

I agree that the lambda thing is an ugly hack and proper trusted blocks 
would be better. However, I wonder how languages with such blocks deal 
with problems such as these:

@safe void someFunction()
{
    int[4] data;
    // Lot's of code
    @trusted
    {
        data.ptr[3] = 42;
    }
}

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;
}

It's not possible to break the set function in @safe code. You could 
probably argue that the trusted block in someFunction should have covered 
the int[2] data definition and that you can also write @trusted functions 
which do not properly check / enforce their parameters and can be broken 
from @safe code.

But still, it seems like applying trusted/safe at function level provides 
stronger guarantees. I wonder how other languages deal with that? Not at 
all and just be extra careful when writing trusted blocks? 

-- 
Johannes