Hello,

I've recently started building a little REST application on vibe.d. I decided to use the "database" library, as I need to communicate with the PostgreSQL instance.

During the compilation I see the deprecation warning:
"Non-@safe methods are deprecated in REST interfaces"

So two questions rise:

1. Will non-@safe methods in REST be disallowed someday?
2. Isn't it too restrictive? If it IS to be disallowed someday, I just won't be able to call most libraries from REST, as I expect the database library for example is definitely not @safe and cannot be.

If I post in the wrong forum, please drop me a line where should I post instead.

On Tuesday, 10 July 2018 at 13:14:24 UTC, Piotr Mitana wrote:
> Hello,
>
> I've recently started building a little REST application on vibe.d. I decided to use the "database" library, as I need to communicate with the PostgreSQL instance.
>
> During the compilation I see the deprecation warning:
> "Non-@safe methods are deprecated in REST interfaces"
>
> So two questions rise:
>
> 1. Will non-@safe methods in REST be disallowed someday?
> 2. Isn't it too restrictive? If it IS to be disallowed someday, I just won't be able to call most libraries from REST, as I expect the database library for example is definitely not @safe and cannot be.
>
> If I post in the wrong forum, please drop me a line where should I post instead.

It's supposed to make webservers safe and not crash because of segmentation faults, etc.

If you still want to write code like you are used to and don't care about that in your webserver, just mark everything in the implementation @trusted (but @safe in the interface) and it will be fine.

On Tuesday, 10 July 2018 07:24:43 MDT WebFreak001 via Digitalmars-d-learn wrote:
> On Tuesday, 10 July 2018 at 13:14:24 UTC, Piotr Mitana wrote:
> > Hello,
> >
> > I've recently started building a little REST application on vibe.d. I decided to use the "database" library, as I need to communicate with the PostgreSQL instance.
> >
> > During the compilation I see the deprecation warning: "Non-@safe methods are deprecated in REST interfaces"
> >
> > So two questions rise:
> >
> > 1. Will non-@safe methods in REST be disallowed someday?
> > 2. Isn't it too restrictive? If it IS to be disallowed someday,
> > I just won't be able to call most libraries from REST, as I
> > expect the database library for example is definitely not @safe
> > and cannot be.
> >
> > If I post in the wrong forum, please drop me a line where should I post instead.
>
> It's supposed to make webservers safe and not crash because of segmentation faults, etc.
>
> If you still want to write code like you are used to and don't care about that in your webserver, just mark everything in the implementation @trusted (but @safe in the interface) and it will be fine.

Ideally, in general, any @system code should be verified as @trusted and mark with @trusted in the narrowest piece of code possible. Having higher level functions be @system usually means that no attempt was made to make it @safe, so it's unlikely to have been verified for memory safety and definitely risks having memory problems.

Now, whether vibe.d needs to insist on it, I don't know, but if it does, then its API can be @safe, and any code using it can rely on it being @safe, whereas if that interface does not require @safe, then the @safety depends on the specific implementation, and the code using it is likely either forced to use @trusted without actually verifying that the code is @safe (which is not good) or to give up on @safe. In general, @system interfaces are a terrible idea if you want to be able to use @safe. Unless the interface itself is doing something that is clearly @system regardless of the actual implementation, the @system aspects generally are a detail of the implementation, and the programmer writing it should be manually verifying it for @safety and using @trusted where appropriate (preferably as narrowly as possible so that as much of the checking as possible is left up to the compiler).

Of course, if you don't want to bother with @safe or verifying your code for @safety, then having an @safe interface with an implementation using @system features can be pretty annoying, but with any program of real size, @safety can become extremely important, and vibe.d is definitely aimed at being used in serious production code where it's going to matter.

- Jonathan M Davis

On Tuesday, 10 July 2018 at 13:24:43 UTC, WebFreak001 wrote:
> It's supposed to make webservers safe and not crash because of segmentation faults, etc.
>
> If you still want to write code like you are used to and don't care about that in your webserver, just mark everything in the implementation @trusted (but @safe in the interface) and it will be fine.

I understand the motivation of this and this motivation is undoubtly correct.

The problem is when you use the libraries, especially those interfacing with C code. The intention of @trusted is to use it to mark the code that *is* memory safe, but it cannot be verified automatically by the compiler (for example required checks are done before an array access).

That's why there is a problem with the libraries that are *not* safe - or at least I don't know the code and cannot verify that they are.

On Wednesday, 11 July 2018 01:46:10 MDT Piotr Mitana via Digitalmars-d-learn wrote:
> On Tuesday, 10 July 2018 at 13:24:43 UTC, WebFreak001 wrote:
> > It's supposed to make webservers safe and not crash because of segmentation faults, etc.
> >
> > If you still want to write code like you are used to and don't care about that in your webserver, just mark everything in the implementation @trusted (but @safe in the interface) and it will be fine.
>
> I understand the motivation of this and this motivation is undoubtly correct.
>
> The problem is when you use the libraries, especially those interfacing with C code. The intention of @trusted is to use it to mark the code that *is* memory safe, but it cannot be verified automatically by the compiler (for example required checks are done before an array access).
>
> That's why there is a problem with the libraries that are *not* safe - or at least I don't know the code and cannot verify that they are.

Well, you should be able to at least verify that your usage of the library is @safe. The internals may have problems, but if you've verified all of your code and marked it as @trusted, then the compiler can check the rest of your code, and if there _is_ a memory corruption problem, you know where to look - any @trusted code and then any libraries you're using. But if you just give up and let all of your code be @system, then you lose out on all of the benefits of the compiler verifying your code. The C binding in druntime are typically marked with @trusted so long as their API is @safe (and thus any @safety bugs in using it are inside the C implementation and not due to misuing the function), since if we don't do that, then @safe becomes pretty useless pretty fast in real world programs. At some point, you have to trust that the C functions are doing their jobs properly, but regardless of whether they are, @trusted allows you to narrow down the problem when there is a memory corruption issue while allowing most of your program to be verified by the compiler - which is the point.

- Jonathan M Davis