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

Add method to get the full match of a Captures without an unwrap #1210

Closed
ultrabear opened this issue Jul 14, 2024 · 2 comments
Closed

Add method to get the full match of a Captures without an unwrap #1210

ultrabear opened this issue Jul 14, 2024 · 2 comments

Comments

@ultrabear
Copy link

A Problem

The current design of regex::Captures has a single way of getting the full match that was captured, via Captures.get(0), this is doc guaranteed to always be Some(Match).

The plain issue is that users of the crate must either match on a case that will never happen, or more likely will just call unwrap because the docs said it was ok, this is not ideal as clippy and code reviewers both dislike uses of unwrap, so now you also need a comment explaining that yes its ok
I wrote this in my code today:

// docs said this unwrap is ok
let item = capture.get(0).unwrap();

A Solution

The simple approach to improve downstream users code legibility: providing a method that gets the full match for us

// potential name 1
Captures::as_match -> Match
// potential name 2
Captures::full -> Match

Implementations

There is one simple implementation route I can think of, and potentially a second special one depending on the layout of the regex internals:

  1. Just call .get(0) and unwrap internally, this is what users will likely do anyways, but now the liability has moved to the regex crate, not each user
  2. If the full match is stored separately in a typed manner internally, just grab that internal object and return it, no possible panic at all
@ultrabear
Copy link
Author

Closing as dup of #1146 oops, I was under the impression this had not been opened yet due to a discussion in the community server

@ultrabear ultrabear closed this as not planned Won't fix, can't repro, duplicate, stale Jul 15, 2024
@BurntSushi
Copy link
Member

Yes, I forgot there was already an open issue. It's okay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants