Remove the notion of an "unknown format" #9535
Closed
Conversation
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
As mentioned in rust-lang#9456, the format! syntax extension would previously consider an empty format as a 'Unknown' format which could then also get coerced into a different style of format on another argument. This is unusual behavior because `{}` is a very common format and if you have `{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly` formatter. This commit removes this coercion, but still retains the requirement that each argument has exactly one format specified for it (an empty format now counts as well). Perhaps at a later date we can add support for multiple formats of one argument, but this puts us in at least a backwards-compatible situation if we decide to do that.
bors
added a commit
that referenced
this pull request
Sep 27, 2013
As mentioned in #9456, the format! syntax extension would previously consider an empty format as a 'Unknown' format which could then also get coerced into a different style of format on another argument. This is unusual behavior because `{}` is a very common format and if you have `{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly` formatter. This commit removes this coercion, but still retains the requirement that each argument has exactly one format specified for it (an empty format now counts as well). Perhaps at a later date we can add support for multiple formats of one argument, but this puts us in at least a backwards-compatible situation if we decide to do that.
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Oct 6, 2022
…ithout_eq_to_nursery, r=xFrednet Moved derive_partial_eq_without_eq to nursery changelog: Moves: Move `derive_partial_eq_without_eq` to `nursery` (now allow-by-default) [rust-lang#9536](rust-lang/rust-clippy#9536) Closes: rust-lang/rust-clippy#9530
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.
This is unusual behavior because
{}is a very common format and if you have{0} {0:?}you wouldn't expect them both to be coereced to thePolyformatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).
Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.