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

[Timon Gehr]

On 15.01.20 19:08, Walter Bright wrote:
> On 1/9/2020 10:47 AM, Johannes Pfau wrote:
>> I agree that the lambda thing is an ugly hack and proper trusted blocks
>> would be better.
> 
> It's intended to be that way. Bad language design is where the simple, 
> straightforward code is considered bad form, for example, in C++:
> 
>      void foo(int array[])  // bad, boo hiss
> 
>      #include <vector>
>      void foo(std::vector<int> array);  // good, you get a gold star
> ...

Or perhaps

#include <vector>
void foo(std::vector<int> const &array);

> Besides, most of the ugliness I've seen comes from excessively trying to 
> reduce the number of characters. Making it a regular nested function 
> with a name makes it nice.
> ...

Maybe it looks nice. A @trusted nested function that depends on 
enclosing @safe code to ensure memory safety is however still not valid.

> ...
> 
> Let's make it look nicer:
> 
>    @safe void someFunction()
>    {
>       int[4] data;
>       // Lot's of code
> 
>       @trusted void set() { data.ptr[3] = 42; }
> 
>       set();
>    }
> 
> 
>> But still, it seems like applying trusted/safe at function level provides
>> stronger guarantees.
> 
> It also makes it easier for both the compiler and user to reason about. 
> The user doesn't need to bother wondering/worrying if the compiler will 
> detect breaking the @trusted code by changing the @safe code.

It will not. The "nice" version is bad.