Making the following code illegal:

import std.stdio;
@safe {
int test1() @system {
    int* p=new int;
    *p++=8;
    return 7;
}
}

So if you mark code with @safe you can not mark parts of it to be @system. This would make things possible like compile time import of configurations, which would currently impossible in a safe way.

For importing the config file you would simply do:

@safe {
 mixin(import("app.cfg"));
}

Guaranteeing that the code in app.cfg has to be safe.

I thought of some wrapper like safeImport() which searches the code for @system or @trusted and rejects the code if one of them is found. But this is quite hard to do it right, especially with mixin's. So it's probably best if the compiler handles this.

What do you think. Should I file a bug report?

Best regards,

Robert

On 02/06/2013 07:26 PM, Robert wrote:
> Making the following code illegal:
>
> import std.stdio;
> @safe {
> int test1() @system {
>      int* p=new int;
>      *p++=8;
>      return 7;
> }
> }
>
> So if you mark code with @safe you can not mark parts of it to be
> @system. This would make things possible like compile time import of
> configurations, which would currently impossible in a safe way.
>
> For importing the config file you would simply do:
>
> @safe {
>   mixin(import("app.cfg"));
> }
>
> Guaranteeing that the code in app.cfg has to be safe.
>
> I thought of some wrapper like safeImport() which searches the code for
> @system or @trusted and rejects the code if one of them is found. But
> this is quite hard to do it right, especially with mixin's. So it's
> probably best if the compiler handles this.
>
> What do you think. Should I file a bug report?
> ...

I think so, yes.

06-Feb-2013 22:26, Robert пишет:
> Making the following code illegal:
>
> import std.stdio;
> @safe {
> int test1() @system {
>      int* p=new int;
>      *p++=8;
>      return 7;
> }
> }
>
> So if you mark code with @safe you can not mark parts of it to be
> @system. This would make things possible like compile time import of
> configurations, which would currently impossible in a safe way.
>
> For importing the config file you would simply do:
>
> @safe {
>   mixin(import("app.cfg"));
> }
>

Nice example.

> Guaranteeing that the code in app.cfg has to be safe.
>
> I thought of some wrapper like safeImport() which searches the code for
> @system or @trusted and rejects the code if one of them is found. But
> this is quite hard to do it right, especially with mixin's. So it's
> probably best if the compiler handles this.
>
> What do you think. Should I file a bug report?
>

Yup.

-- 
Dmitry Olshansky

Done: http://d.puremagic.com/issues/show_bug.cgi?id=9463

Best regards,

Robert


> >
> > What do you think. Should I file a bug report?
> >
> 
> Yup.
> 

On Wednesday, 6 February 2013 at 18:26:17 UTC, Robert wrote:
> Making the following code illegal:
>
> import std.stdio;
> @safe {
> int test1() @system {
>     int* p=new int;
>     *p++=8;
>     return 7;
> }
> }
>
> So if you Mark code with @safe you can not Mark parts of it to be @system. This would make things possible like compile time import of configurations, which would currently impossible in a safe way.

 Agreed, although you can always tighten the code rather than limit it. @trusted would be the in between cases.

 So this would be the behavior?

  @system {
    int test1() {} //@system
    int test1() @safe {}    //of course!
    int test1() @trusted {} //of course!
    a = b;
  }

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

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

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

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

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.

The purpose of my proposal was to be able to sandbox code. It is quite
different, whether you allow the sandboxed code calling a trusted
function, you declared or allowing the sandboxed code to declare a
trusted function, which would simply break the sandbox.
On Thu, 2013-02-07 at 01:07 +0100, Era Scarecrow wrote:
> 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).

Ok. Now I see what you mean. Good point, maybe it makes sense to extend my proposal to simply state that @trusted, @system and @safe are simple not overridable.

On Thu, 2013-02-07 at 01:07 +0100, Era Scarecrow wrote:
> >>    @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.

Am Wed, 06 Feb 2013 22:46:50 +0400
schrieb Dmitry Olshansky <dmitry.olsh@gmail.com>:

> 06-Feb-2013 22:26, Robert пишет:
> > Guaranteeing that the code in app.cfg has to be safe.
> >
> > I thought of some wrapper like safeImport() which searches the code for @system or @trusted and rejects the code if one of them is found. But this is quite hard to do it right, especially with mixin's. So it's probably best if the compiler handles this.
> >
> > What do you think. Should I file a bug report?
> >
> 
> Yup.
> 

But isn't @system completely useless if it can't overwrite @safe as @system is always the default?