You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 oklet 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 1Captures::as_match -> Match// potential name 2Captures::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:
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
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
The text was updated successfully, but these errors were encountered:
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 beSome(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:
A Solution
The simple approach to improve downstream users code legibility: providing a method that gets the full match for us
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:
The text was updated successfully, but these errors were encountered: