Fix Issue 6644 - std.stdio write/writef(ln) are not @trusted #2230
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Squashed commit: [0699330] Added unit tests [9a43947] Made File.writeln (and family) into UFCS templated functions so they can infer @safe/@trusted/etc. Also wrapped stdout in @trusted private function so writeln (and family) free functions don't always infer @System. Lots of unit tests are still needed.
If they can't infer safety, that that's a bug, and I really don't like the idea of moving to free functions just to get around that. It opens the door for symbol conflicts and the like. It would be far better IMHO to fix the compiler bug. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://issues.dlang.org/show_bug.cgi?id=6644
More discussion here: http://stackoverflow.com/questions/19101305/how-can-i-do-i-o-in-safe-functions-in-d
Changes I have made to get write and family callable from
@safecode:LockingTextWriterand factory function@trusted- I didn't see anything inherently unsafe about the way it manages the lock. I'm certainly open to correction, though.File.write,File.writeln,File.writefandFile.writeflnto non-member functions (UFCS). This is because member functions, even templated ones, cannot infer safety. If you do not infer safety then you can calltoStringon@systemtypes (that may actually be unsafe) from@safecode.stdoutglobal variable's usage in aprivate @trustedproperty that is used bywriteand friends. If this is not done they always infer to@systemdue to accessing a global variable. I'm not 100% sure this is safe to to, but with the property being private all external use of the global will still be@system.