Description
It is sometimes appropriate for a program to close its standard output stream long before it's done running. For instance, I have a C program that sets up some system-wide state, waits for its parent to be done using that setup, and then tears it down again. (It's a separate program from the parent because it has to be setuid.) It notifies the parent that it's done setting up by closing its stdout, which is expected to be a pipe.
You can do this in Rust, but only by going behind the stdlib's back and calling libc::close(1). I would like there to be an official way to do this, without going behind the stdlib's back. A concrete proposal: Stdout (and Stderr) add a close method. These flush buffered output, close the underlying OS-level file descriptor, and then immediately reopen it on /dev/null, taking care to ensure that the well-known fd number is retained. It remains OK to use io::stdout() after calling close on it.
(Reopening the OS-level file descriptor on /dev/null is to accommodate third-party libraries that may assume it is always safe to write to file descriptors 1 and/or 2, and/or that the open() primitive will never return descriptors numbered 0, 1, or 2.)
(Windows doesn't exactly have "file descriptors" but it does have the concept of "standard handles" and there is a 1:1 mapping from the Unixy terms I used above to Windows equivalents.)
(For consistency, the internal method for "replacing Stdout and Stderr with an arbitrary instance of Write" (mentioned in #40007) should also perform this close operation.)