Use split_once in FromStr docs

[Dav1dde]

Current implementation:

    fn from_str(s: &str) -> Result<Self, Self::Err> {
        let coords: Vec<&str> = s.trim_matches(|p| p == '(' || p == ')' )
                                 .split(',')
                                 .collect();

        let x_fromstr = coords[0].parse::<i32>()?;
        let y_fromstr = coords[1].parse::<i32>()?;

        Ok(Point { x: x_fromstr, y: y_fromstr })
    }

Creating the vector is not necessary, split_once does the job better.

Alternatively we could also remove trim_matches with strip_prefix and strip_suffix:

        let (x, y) = s
            .strip_prefix('(')
            .and_then(|s| s.strip_suffix(')'))
            .and_then(|s| s.split_once(','))
            .unwrap();

The question is how much 'correctness' is too much and distracts from the example. In a real implementation you would also not unwrap (or originally access the vector without bounds checks), but implementing a custom Error and adding a From<ParseIntError> and implementing the Error trait adds a lot of code to the example which is not relevant to the FromStr trait.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon.

Please see the contribution instructions for more information.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[JohnTitor]

Removing unwrap is indeed overkill but I'd like to have strip_{prefix, suffix}, could you update the example?

[Dav1dde]

I've updated the example to use strip_prefix and strip_suffix (like mentioned in the original PR).

@JohnTitor I am not sure what the proper process here is, can I change the label back to S-waiting-on-review? I couldn't find anything in the docs.

[Dav1dde]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[JohnTitor]

I am not sure what the proper process here is, can I change the label back to S-waiting-on-review? I couldn't find anything in the docs.

Yeah, you're right, you could also use the shorthand described in https://github.com/rust-lang/triagebot/wiki/Shortcuts.

@bors r+ rollup

[bors]

📌 Commit c1c1abc has been approved by JohnTitor

It is now in the queue for this repository.