vibe.d: problematic "Non- at safe methods are deprecated in REST interfaces"

[Jonathan M Davis]

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- at safe methods are deprecated in REST interfaces"
> >
> > So two questions rise:
> >
> > 1. Will non- at 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