• Chris Wright (11/11) Jan 21 2016 I wanted to use std.array.insertInPlace in a @safe module. It's not
• Steven Schveighoffer (22/33) Jan 22 2016 @trusted is not something that should be used lightly. If you mark an

Chris Wright <dhasenan gmail.com> writes:

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?

Steven Schveighoffer <schveiguy yahoo.com> writes:

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