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

Walter Bright newshound2 at digitalmars.com
Wed Jan 15 18:08:33 UTC 2020


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

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.


> 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.

Exactly right.

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.


More information about the Digitalmars-d mailing list