make @safe "non-escapable"?

[Era Scarecrow]

On Wednesday, 6 February 2013 at 22:56:56 UTC, Robert wrote:
>>   So this would be the behavior?
>> 
>>    @system {
>>      int test1() {} //@system
>>      int test1() @safe {}    //of course!
>>      int test1() @trusted {} //of course!
>>      a = b;
>>    }
> Yeah.

>>    @trusted { //disallowed for (bulk) function/type 
>> declarations
>>               //intended only for bits of code or for 
>> functions:
>>               //Otherwise an easy unchecked breeding ground 
>> for bugs!
>>      int test1() {}          //error
>>      int test1() @safe {}    //error
>>      int test1() @system {}  //error
>>      int test1() @trusted {} //error, yes it is
>>                              //even if explicit
>>      a = b;
>>    }
>
> Why would the @safe definition be an error?

  Because getting adding functions to a @trusted area would allow 
some lazy programmers to say 'it just works', it would be so easy 
to just remove @safe (and it would work). In general @trusted 
(code blocks) in my mind shouldn't allow function/structs/any 
type of extra declarations as it would be so easy to make it 
'seem safe' while not properly checked, or adding a new function 
in while not wanting to move it back and forth between writing & 
testing.

  Sides allowing @safe in a @trusted zone while nothing else works 
doesn't make sense. It would be better to disallow period all 
rather than give an easy route for problems later. At least with 
@system and @safe code you know where you stand.

  This is a personal opinion though.

>>    @safe {
>>      int test1() {} //@safe
>>      int test1() @trusted {} //will happen from time to time.
>>      int test1() @system {}  //error, cannot weaken code's
>>                              //restrictions
>>      a = b; //only if safe
>>    }
>
> The @trusted definition must not be allowed either. @trusted 
> good is as good as @system code in this context, because the 
> compiler guarantees nothing.

  True, but if you have one or two functions that break @safe but 
you know are safe, then you need to override it. Otherwise you 
have extra hoops to go through. If @safe code can't call @trusted 
code, then this is a non-issue (as it's just another step/tier 
towards safe).

   @safe struct S {
     void func1();
     void func2();
     void func3();
     void func4() @trusted;
   }

  vs

   struct S {
     void func1() @safe;
     void func2() @safe;
     void func3() @safe;
     void func4() @trusted;
   }

  or

   struct S {
     @safe {
       void func1();
       void func2();
       void func3();
     }
     void func4() @trusted;
   }

  Also seems like if you had to add a @trusted function you'd have 
a lot of extra work just to get it 'correct' rather than allowing 
a @trusted.