forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc]. There are a number of breaking changes as a part of this commit which will need to be handled to migrated old code: * A number of formatting traits have been removed: String, Bool, Char, Unsigned, Signed, and Float. It is recommended to instead use Show wherever possible or to use adaptor structs to implement other methods of formatting. * The format specifier for Boolean has changed from `t` to `b`. * The enum `FormatError` has been renamed to `Error` as well as becoming a unit struct instead of an enum. The `WriteError` variant no longer exists. * The `format_args_method!` macro has been removed with no replacement. Alter code to use the `format_args!` macro instead. * The public fields of a `Formatter` have become read-only with no replacement. Use a new formatting string to alter the formatting flags in combination with the `write!` macro. The fields can be accessed through accessor methods on the `Formatter` structure. Other than these breaking changes, the contents of std::fmt should now also all contain stability markers. Most of them are still #[unstable] or #[experimental] [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md [breaking-change] Closes rust-lang#18904
- Loading branch information
1 parent
e09d986
commit 4af3494
Showing
48 changed files
with
291 additions
and
347 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
Oops, something went wrong.
4af3494
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=aturon
4af3494
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(alexcrichton editing away r- due to rust-lang#19040 (comment))
It's premature to mark
print!
andprintln!
as stable without addressing the concerns with them or at least deciding that the design is acceptable and documenting the compromises. I would expect the fact that Rust has a wrappedstdout
requiring virtual method calls to fall under runtime reform, and I also think the misuse ofpanic!
to deal with unpredictable runtime errors needs to be addressed in some way.4af3494
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@thestinger A couple of points:
println!
.println!
is a convenience macro; whatever changes occcur as part of runtime reform, it seems clear we'll be able to go on supporting some convenient means of printing to stdio/stderr.println!
macro. If all you want is a convenient way to print something out, go for it.4af3494
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have time to read through all of the RFCs. Only a fraction of those proposals make it to real pull requests, and many significant changes skip the process altogether anyway.
It returning a value or having different buffering semantics would be a breaking change to the API.
It doesn't just panic on I/O failure, it panics on broken pipes which is a completely normal part of *nix programming. Nearly every program used in shell pipelines has to cope with broken pipes when a program like
head
closes early.4af3494
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
println!
isn't intended to be usable in small command-line programs, then I don't know why it exists.4af3494
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r+ per rust-lang#19040 (comment)