I wanted to use std.array.insertInPlace in a @safe module. It's not marked @safe or @trusted. The string implementation uses pointer arithmetic, and the non-string implementation uses memmove.

Should things like this be marked @trusted in general?

Presumably if a function isn't memory-safe, it doesn't just cause memory errors arbitrarily; there's likely something the caller has to do to ensure the function doesn't crash or cause memory corruption. It seems like that should be documented. When it's not documented, I start feeling a bit paranoid.

Should it be a bug if a non-@safe, non-@trusted function doesn't document what you need to do to call it safely?

On 1/21/16 10:43 PM, Chris Wright wrote:
> I wanted to use std.array.insertInPlace in a @safe module. It's not
> marked @safe or @trusted. The string implementation uses pointer
> arithmetic, and the non-string implementation uses memmove.
>
> Should things like this be marked @trusted in general?
>
> Presumably if a function isn't memory-safe, it doesn't just cause memory
> errors arbitrarily; there's likely something the caller has to do to
> ensure the function doesn't crash or cause memory corruption. It seems
> like that should be documented. When it's not documented, I start feeling
> a bit paranoid.

@trusted is not something that should be used lightly. If you mark an entire function @trusted, it has to be hand checked for safety. Any possible corruption must be dealt with. This is not easy to do.

Not to mention, any changes to the function must be hand checked since the compiler is not checking them.

If a function is a template, then I think we should never mark it @trusted, as this can result in calling unsafe @system functions without intention (imagine that something that's normally an innocuous field is actually a method that is system, now you just escaped it). In addition, templates will naturally infer @safety if not marked (I assume this was the intention for insertInPlace).

Typically, we use a trusted escape block (a lambda marked trusted that is immediately called) to do unsafe things within a @safe function.

I haven't looked at the function in question, but I would guess that most of phobos should be marked or inferred @safe, with @trusted escapes. That one does seem like one that should be @safe in most cases.

> Should it be a bug if a non-@safe, non-@trusted function doesn't document
> what you need to do to call it safely?

If there is a dependency on @safety, it should probably be noted. That is, if there are ways to call it that allow it to be @safe in some cases and @system in others, then we should identify those in the docs. Is it a bug? No more than any other doc omission is a "bug".

-Steve