You do not have, or at least not directly. I / O requires system calls, which means that C functions and C functions will not be @safe . And since writeln is currently invoking printf under the hood, it definitely won't be @safe , because it's trivial to do unsafe things with printf (for example, giving it %s ) and then passing it an integer instead of a string). Perhaps, in some cases, you can do writeln @trusted , but I do not know what it will all be connected with. It will depend on how it is implemented.
It was expected that any non-trivial D program would use @system code. The trick is to isolate it. Most of your program will hopefully be @safe , but parts of it should be @system . However, you only need to study a small section of your program to ensure memory security. Once you manually verify that the function that calls the @system functions is actually memory safe, you can mark it as @trusted , and then you can use it in the @safe code.
Unfortunately, it is also likely that some of the main things in druntime and Phobos will be @system based on what it does with low-level materials, and not all of this has been noted with @trusted , as it should be (for example, std.array.appender can be @system when it probably should be @trusted - I'm not sure what it is now, but probably depends on the type of element in your array). Thus, it is likely that some improvements will need to be made to some standard library materials in order to better support @safe (this happens, but I don’t know where it all stands right now), and you can end up using more of @trusted places right now than you will be in the future. writeln may or may not be @safe or @trusted in the future. But it definitely won't if the types you use with it don't have @safe or @trusted toString functions, so the writeln @safe part depends on what you are using it no matter how it is implemented. However, at the moment it is not @safe or @trusted even with built-in types, so for now, you're out of luck.
If you really want to, you can create a wrapper for writeln that was @trusted , but you need to be careful to make sure the code is actually memory-safe - and just create a templated wrapper and its marking @trusted not going to shorten it , because then you will treat it like @safe no matter what type you passed it to. Therefore, it’s best to just not wrap it and then mark the caller as @trusted if you are sure that this particular use of writeln is memory safe. Of course, this also indicates why functions like writeln are currently @system in the first place: it is often difficult to write @trusted boilerplate code without trusting material that should not be trusted (as this depends on the template arguments). Attribute output often takes care of the problem, but if the boilerplate code does something that should be @trusted , it becomes difficult to mark part of the code as @trusted and leave the rest to output, especially if the template arguments are mixed with @system material. I expect that we will nevertheless disassemble it for all standard library materials.
Jonathan m davis
source share