-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
10 additions
and
9 deletions.
There are no files selected for viewing
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,29 +1,30 @@ | ||
- Start Date: (fill me in with today's date, YYYY-MM-DD) | ||
- Start Date: 2015-03-25 | ||
- RFC PR: (leave this empty) | ||
- Rust Issue: (leave this empty) | ||
|
||
# Summary | ||
|
||
One para explanation of the feature. | ||
When calling `println!` it currently causes a panic if `stdout` does not exist. Change this to ignore this specific error and simply void the output. | ||
|
||
# Motivation | ||
|
||
Why are we doing this? What use cases does it support? What is the expected outcome? | ||
On linux `stdout` almost always exists, so when people write games and turn off the terminal there is still an `stdout` that they write to. Then when getting the code to run on Windows, when the console is disabled, suddenly `stdout` doesn't exist and `println!` panicks. This behavior difference is frustrating to developers trying to move to Windows. | ||
|
||
There is also precedent with C and C++. On both Linux and Windows, if `stdout` is closed or doesn't exist, neither platform will error when printing to the console. | ||
|
||
# Detailed design | ||
|
||
This is the bulk of the RFC. Explain the design in enough detail for somebody familiar | ||
with the language to understand, and for somebody familiar with the compiler to implement. | ||
This should get into specifics and corner-cases, and include examples of how the feature is used. | ||
Change the internal implementation of `println!` `print!` `panic!` and `assert!` to not `panic!` when `stdout` or `stderr` doesn't exist. When getting `stdout` or `stderr` through the `std::io` methods, those versions should continue to return an error if `stdout` or `stderr` doesn't exist. | ||
|
||
# Drawbacks | ||
|
||
Why should we *not* do this? | ||
Hides an error from the user which we may want to expose and may lead to people missing panicks occuring in threads. | ||
|
||
# Alternatives | ||
|
||
What other designs have been considered? What is the impact of not doing this? | ||
* Make `println!` `print!` `panic!` `assert!` return errors that the user has to handle. | ||
* Continue with the status quo and panic if `stdout` or `stderr` doesn't exist. | ||
|
||
# Unresolved questions | ||
|
||
What parts of the design are still TBD? | ||
* Should `std::io::stdout` return `Err` or `None` when there is no `stdout` instead of unconditionally returning `Stdout`? |