Add eprint! and eprintln! macros to the prelude.
#39229
Conversation
These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout. Issue rust-lang#39228.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Adding a new macro requires an RFC, since macros are global and insta-stable. See rust-lang/rfcs#1653 for a recent RFC that was like this. Could you do that please? Thanks! |
|
(We can always re-open this PR if the RFC goes through, as well.) |
|
(On a personal note; I've always felt like this was missing, and agree with the other comments that I'm broadly in favor) |
Can do, but possibly not for a couple days. |
|
RFC posted here. |
| reason = "implementation detail which may disappear or be replaced at any time", | ||
| issue = "0")] | ||
| #[doc(hidden)] | ||
| pub fn _eprint(args: fmt::Arguments) { |
There was a problem hiding this comment.
Is it possible to merge this with _print()?
| /// | ||
| /// Panics if writing to `io::stderr()` fails. | ||
| #[macro_export] | ||
| #[unstable(feature = "eprint", issue="39228")] |
I mean to (well, to open a new one, apparently that's better for bors) but I got bogged down in revising The Book to match, plus a lot of other work. Real Soon Now™. |
Add `eprint!` and `eprintln!` macros to the prelude. These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout. Issues rust-lang#39228 and rust-lang#40528; previous PR rust-lang#39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615. I have _not_ revised this any since the original submission; I will do that later this week. I wanted to get this PR in place since it's been quite a while since the RFC was merged. Known outstanding review comments: * [x] @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it. * [x] @nodakai asked if it were possible to merge the internal methods `_print` and `_eprint` - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out. Please let me know if I missed anything.
Add `eprint!` and `eprintln!` macros to the prelude. These are exactly the same as `print!` and `println!` except that they write to stderr instead of stdout. Issues rust-lang#39228 and rust-lang#40528; previous PR rust-lang#39229; accepted RFC rust-lang/rfcs#1869; proposed revision to The Book rust-lang/book#615. I have _not_ revised this any since the original submission; I will do that later this week. I wanted to get this PR in place since it's been quite a while since the RFC was merged. Known outstanding review comments: * [x] @steveklabnik requested a new chapter for the unstable version of The Book -- please see if the proposed revisions to the second edition cover it. * [x] @nodakai asked if it were possible to merge the internal methods `_print` and `_eprint` - not completely, since they both refer to different internal globals which we don't want to expose, but I will see if some duplication can be factored out. Please let me know if I missed anything.
These are exactly the same as
print!andprintln!except that they write to stderr instead of stdout. See issue #39228 and/or https://internals.rust-lang.org/t/extremely-pre-rfc-eprintln/4635 for further discussion. Currently gated on#![feature(eprint)]but I hope they can be stabilized in time for 1.16.I have not checked through the documentation for places where these should be used / recommended in place of
print(ln)!.