Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amend RFC 517: Add material for stdio #899

Merged
merged 6 commits into from
Mar 13, 2015
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 46 additions & 3 deletions text/0517-io-os-reform.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,7 @@ follow-up PRs against this RFC.
* [Errors]
* [Channel adapters]
* [stdin, stdout, stderr]
* [Printing functions]
* [std::env]
* [std::fs]
* [Free functions]
Expand All @@ -72,7 +73,6 @@ follow-up PRs against this RFC.
* [TCP]
* [UDP]
* [Addresses]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to delete this when the std::net RFC landed.

* [std::net] (stub)
* [std::process]
* [Command]
* [Child]
Expand Down Expand Up @@ -1155,7 +1155,49 @@ RFC recommends they remain unstable.
#### `stdin`, `stdout`, `stderr`
[stdin, stdout, stderr]: #stdin-stdout-stderr

> To be added in a follow-up PR.
The current `stdio` module will be removed in favor of three constructors:

* `stdin` - returns a handle to a **globally shared** to the standard input of
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

globally shared _____?

the process which is buffered as well. All operations on this handle will
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"buffered as well" here seems to contradict below where it says it won't have BufRead implemented.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be buffered, but it won't implement BufRead, just like stdin does today: http://doc.rust-lang.org/std/old_io/stdio/fn.stdin.html

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, it seems this 'all' isn't quite true? (Or is it referring to the internals too.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How so? (I may be missing something)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are operations other than lock on Stdin, meaning a user can do things with it without locking. (I'm now inclined to believe I just misread: and this sentence is saying those operations would just call lock internally.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, yes this is just saying that all methods will call lock internally

first require acquiring a lock to ensure access to the shared buffer is
synchronized. The handle can be explicitly locked for a critical section so
relocking is not necessary.

The `Read` trait will be implemented directly on the returned `Stdin` handle
but the `BufRead` trait will not be (due to synchronization concerns). The
locked version of `Stdin` will provide an implementation of `BufRead`.

The design will largely be the same as is today with the `old_io` module.

* `stderr` - returns a **non buffered** handle to the standard error output
stream for the process. Each call to `write` will roughly translate to a
system call to output data when written to `stderr`.

* `stdout` - returns a **locally buffered** handle to the standard output of the
current process. The amount of buffering can be decided at runtime to allow
for different situations such as being attached to a TTY or being redirected
to an output file. The `Write` trait will be implemented for this handle.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will the interface to change the buffering look like?


The `stderr_raw` constructor is removed because the handle is no longer buffered
and the `stdin_raw` and `stdout_raw` handles are removed to be added at a later
date in the `std::os` modules if necessary.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's necessary right now.


#### Printing functions
[Printing functions]: #printing-functions

The current `print`, `println`, `print_args`, and `println_args` functions will
all be "removed from the public interface" by [prefixing them with `__` and
marking `#[doc(hidden)]`][gh22607]. These are all implementation details of the
`print!` and `println!` macros and don't need to be exposed in the public
interface.

[gh22607]: https://github.com/rust-lang/rust/issues/22607

The `set_stdout` and `set_stderr` functions will be moved to a new
`std::fmt::output` module and renamed to `set_print` and `set_panic`,
respectively. These new names reflect what they actually do, removing a
longstanding confusion. The current `stdio::flush` function will also move to
this module and be renamed to `flush_print`.

### `std::env`
[std::env]: #stdenv
Expand All @@ -1173,7 +1215,8 @@ and the signatures will be updated to follow this RFC's

* `vars` (renamed from `env`): yields a vector of `(OsString, OsString)` pairs.
* `var` (renamed from `getenv`): take a value bounded by `AsOsStr`,
allowing Rust strings and slices to be ergonomically passed in. Yields an `Option<OsString>`.
allowing Rust strings and slices to be ergonomically passed in. Yields an
`Option<OsString>`.
* `var_string`: take a value bounded by `AsOsStr`, returning `Result<String,
VarError>` where `VarError` represents a non-unicode `OsString` or a "not
present" value.
Expand Down