@safe, @trusted, @system

[IgorDeepakM]

This needs a discussion in a new thread I think. This is regarding the future of the state @trusted and also unsafe blocks. In my opinion we only need safe and unsafe designations and those two states can cover everything together with unsafe blocks. @safe can be declared on functions. @unsafe can be declared on blocks @safe and removing @trusted also simplifies the compiler and design work what is supposed to go in there.

There was a lot of debate about if extern(C) was supposed to be @safe or @System. For the sake of the discussion extern(C) is regarded as unsafe unless declared as @safe in these examples.

Example:

extern(C) @safe void myCFunc1(...);
extern(C) void myCFunc2(...)


void main()
{
    myCFunc1(...); // Can be called directly
    @unsafe
    {
        myCFunc2(...); // Can only be called within unsafe blocks
    }
}

The point of the @trusted state was that it would serve as "verified trampoline and interface code". Nothing wrong with that but that extra @trusted state is unnecessary.

extern(C) void myCFunc(...);

void myCTrampoline(...)
{
    @unsafe
    {
       // do some unsafe preparations here
       myCFunc(....);
       // Do more unsafe stuff here associated with the C function
    }
}

void main()
{
    myCTrampoline(...)     // Can be called directly from safe code as it is the default for functions without any attributes
}

The code in the trampoline is usually short enough that it doesn't matter if you use @System or @trusted in terms of safety.

Sometimes you just want to call a few C functions and you don't really care about making trampoline functions or write @safe at extern(C) (let's say it is a library and you don't want to change that code) as they are just used once. It is up to the programmer how they want it. Often when you call FFI functions, there is an unsafe preparations before the call. unsafe blocks enables you to do this inline if you wish to do so.

extern(C) void myCFunc(...);

void main()
{
    @unsafe
    {
       // do some unsafe preparations here
       myCFunc(....);
       // Do more unsafe stuff here associated with the C function
    }
}

Functions with @System attribute can be created just as before and can only called from unsafe code.

@system void unsafeFunction()
{
    ... // Totally unsafe code here without unsafe blocks.
}

As you noticed by now, we can do everything without the @trusted attribute and it is completely unnecessary.

If we want to keep @trusted for compatibility reasons with old D code we can use lowering.

@trusted void trustedFunction()
{
    ... // trusted code in here
}

becomes using lowering

@safe void trustedFunction()
{
    @unsafe
    {
        ... // trusted code in here
    }
}

[Lyratelle]

Jup. This is exactly what I say since long. We need only two states for functions + trusted/unsafe/whatever blocks within a safe function.

But I don't think we need any new keywords like @unsafe. We can stay with @System. @safe can go, as this is the default, and @trusted can only be used on blocks. Very small change.

[ntrel]

The problem that the 3 safe/trusted/system attributes solve is to separate the following:

• memory-safe code - @safe
• unsafe code with a safe interface - @trusted
• unsafe code with an unsafe interface - @system

If you only had safe and unsafe, then there is no distinction between the last two kinds of code.

@trusted does not mean 'let me do unsafe stuff'. It lets you do that, but it is a programming error if any unsafe value escapes @trusted into @safe:

@safe f() {
  int* p = (() @trusted => cast(int*)1000)();
  // programming error even if `p` is never used
  ...
}

The unsafe value of p is accessible in a @safe scope. The solution to cases where p can't be in a smaller non-@safe scope is to correctly annotate f as @trusted.

The problem with that is that then other unsafe stuff may happen anywhere in f by accident. So what we need is a requirement to mark each unsafe expression/statement that occurs inside a @trusted function. The @system attribute could be used for that.

// OK, safety verified by a human, safe interface
@trusted f() {
  int* p = @system(cast(int*)1000)); // OK
  int* q = cast(int*)1000; // Error, need to mark as unsafe
  ...
}

[IgorDeepakM]

// OK, safety verified by a human, safe interface
@trusted f() {
  int* p = @system(cast(int*)1000)); // OK
  int* q = cast(int*)1000; // Error, need to mark as unsafe
  ...
}

Isn't this exactly the same as

// OK, safety verified by a human, safe interface
@safe f() {
    @unsafe
    {
         int* p = cast(int*)1000); // OK
    }
    int* q = cast(int*)1000; // Error, need to mark as unsafe
    ...
}

[quickfur]

I actually favor the idea of unsafe blocks, because it means the rest of the function body would still be subject to @safe checks, something you don't get if you use @trusted today.

If it were up to me, I'd define @safe as a function where the entire function body must be verifiably safe by the compiler; @trusted is the same as @safe except that you're allowed to have @system blocks inside where the safety cannot be automatically verified and it's up to the programmer to do the right thing; and @system functions where all checks are disabled and the programmer takes over the entire responsibility.

The current implementation of @trusted is bad because it turns off all checks inside the function body, and is basically the same as @system except that safe code can call it. IMO it'd be better to enforce safety for most of the function body, only allow small chunks of code to use the escape hatch.

[Lyratelle]

Would be ok for me. I still think @trusted (for functions) is superfluous, as you can easily grap for @trusted blocks, but maybe it's a good idea to make the usage of @System functions more obvious.

[ssvb]

I'm in favour of just keeping the status quo for the sake of not breaking compatibility unnecessarily. Maybe with a long term goal to eventually rename @system to @unsafe as a better fitting name (but support both name variants during a long transition period). Also it would be nice to have a cleaner syntax sugar for the constructs like:

  () @trusted {
    // do something
  }();

[ntrel]

The problem with @trusted blocks/delegate literals is that later, a change in @safe code around one can then violate memory-safety, without changing any @trusted code. This is a gotcha for reviewers.

[Lyratelle]

? changing a function that contains @trusted blocks is changing trusted code. Of course this has to be reviewed with the special care to keep the trust. But it still makes the review easier - you only need to check if any of the inputs of called @System functions has changed (or the values of @System features used), else everything stays fine. And of course if inputs have changed you need to check that they are still ok.

[Lyratelle]

It's funny how this editor changes @System always to have an uppercase S (which the compiler doesn't like) :-)

[IgorDeepakM]

It's a bit annoying that the forum syntax for referencing an existing user collides with the D syntax for attributes.

On way is to have it inside a formatted text block like this @system.

Regardless what you choose, it will be obvious what we mean inside this forum.

[ntrel]

@Lyratelle It's because github markup allows you to @ github users.

[quickfur]

Yeah I always put it inside backticks so that it doesn't accidentally tag some hapless github user who has no idea what D is. :D