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

Change FromStr for String to use Infallible directly #67925

Merged
merged 1 commit into from Feb 20, 2020

Conversation

@petertodd
Copy link
Contributor

petertodd commented Jan 6, 2020

Fixes the confusing documentation on ParseError by making it irrelevant.

It might be fine to mark it as depreciated right now too - I can't imagine much code uses ParseError directly.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jan 6, 2020

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

src/liballoc/string.rs Outdated Show resolved Hide resolved
@petertodd petertodd force-pushed the petertodd:2020-fromstr-infallible branch from 587a893 to 02b3c1c Jan 6, 2020
#[stable(feature = "str_parse_error", since = "1.5.0")]
pub type ParseError = core::convert::Infallible;

#[stable(feature = "rust1", since = "1.0.0")]
impl FromStr for String {
type Err = core::convert::Infallible;
#[inline]
fn from_str(s: &str) -> Result<String, ParseError> {
fn from_str(s: &str) -> Result<String, core::convert::Infallible> {

This comment has been minimized.

Copy link
@lzutao

lzutao Jan 6, 2020

Contributor

Does this make ParseError unused?

This comment has been minimized.

Copy link
@petertodd

petertodd Jan 6, 2020

Author Contributor

Yes. I think the obvious thing for downstream code that needs to specify ParseError for some reason to do is replace it with Infallible. Of course, that's a backwards compatibility issue: your code won't compile with older versions of Rust.

Though I'd expect it to be a fairly rare one, as I doubt much downstream code needs to actually mention ParseError directly.

This comment has been minimized.

Copy link
@shepmaster

shepmaster Jan 6, 2020

Member

This might as well be -> Result<String, Self::Err> to prevent any future churn.

/// defined, but, given that a [`String`] can always be made into a new
/// [`String`] without error, this type will never actually be returned. As
/// such, it is only here to satisfy said signature, and is useless otherwise.
/// This alias exists for backwards compatibility, and will be eventually deprecated.

This comment has been minimized.

Copy link
@shepmaster

shepmaster Jan 6, 2020

Member

Why will it be deprecated? Says who?

This comment has been minimized.

Copy link
@clarfon

clarfon Jan 12, 2020

Contributor

If the never type works on all editions I don't see why people would ever use Infalliable long-term. Deprecation doesn't prevent its usage, just discourage it.

@JohnCSimon

This comment has been minimized.

Copy link
Member

JohnCSimon commented Jan 26, 2020

ping from triage:
@petertodd @shepmaster What is the status of this PR, it's sat idle for a few weeks.

@petertodd petertodd force-pushed the petertodd:2020-fromstr-infallible branch from 02b3c1c to 6935883 Jan 29, 2020
@petertodd

This comment has been minimized.

Copy link
Contributor Author

petertodd commented Jan 29, 2020

@JohnCSimon @shepmaster I changed it to return Self::Err as suggested; should be fine to merge so long as others' think it's a good idea.

@shepmaster

This comment has been minimized.

Copy link
Member

shepmaster commented Jan 29, 2020

The code change itself looks fine, but I'm not cool enough to vet the changes about deprecation.

r? @LukasKalbertodt

@LukasKalbertodt

This comment has been minimized.

Copy link
Member

LukasKalbertodt commented Jan 29, 2020

I think this is fine as is. The only non-doc changes are definitely non-breaking. And mentioning ParseError will be deprecated eventually is fine, as that was part of the initial plan (implemented in #58302). Just to be sure: @SimonSapin does this seem fine to you? (as you've been heavily involved in this discussion.)

@JohnCSimon

This comment has been minimized.

Copy link
Member

JohnCSimon commented Feb 16, 2020

Ping from triage: @SimonSapin - can you please review this?
@LukasKalbertodt is this PR ready to be merged?

src/liballoc/string.rs Outdated Show resolved Hide resolved
Fixes the confusing documentation on `ParseError` by making it
irrelevant.
@petertodd petertodd force-pushed the petertodd:2020-fromstr-infallible branch from 6935883 to 883e69d Feb 19, 2020
@LukasKalbertodt

This comment has been minimized.

Copy link
Member

LukasKalbertodt commented Feb 19, 2020

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 19, 2020

📌 Commit 883e69d has been approved by LukasKalbertodt

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 20, 2020

⌛️ Testing commit 883e69d with merge de362d8...

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 20, 2020

☀️ Test successful - checks-azure
Approved by: LukasKalbertodt
Pushing de362d8 to master...

@bors bors added the merged-by-bors label Feb 20, 2020
@bors bors merged commit de362d8 into rust-lang:master Feb 20, 2020
5 checks passed
5 checks passed
homu Test successful
Details
pr Build #20200219.41 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-7) Linux x86_64-gnu-llvm-7 succeeded
Details
pr (Linux x86_64-gnu-tools) Linux x86_64-gnu-tools succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants
You can’t perform that action at this time.