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

[Paolo Invernizzi]

On Thursday, 9 January 2020 at 18:47:23 UTC, Johannes Pfau wrote:
> 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?

Exactly!

Function level seems to be the proper place to granularly expose 
assumptions and promises in a clean way: put on the stage 
contracts, documentation and the possibility to easily unittest 
it ...

I'm -1 on @trusted blocks