Captures<'t> .at, .name return "" to represent both "matches empty string" and "no match"

[emk]

The methods at and name on Captures<'t> return "" to represent both failed matches and successful matches against the empty string. In the case of at, a programmer can use pos to distinguish between the two situations. But in the case of name, there's no good, public API which allows us to test for a match.

The follow regex has two named matched groups, key and value. value is optional:

// Matches "foo", "foo;v=bar" and "foo;v=".
regex!(r"(?P<key>[a-z]+)(;v=(?P<value>[a-z]*))?");

We can access value using caps.name("value"), but there's no way for us to distinguish between the "foo" and "foo;v=" cases.

Even if we're willing to treat both meanings of "" as "failed match", it's still a nuisance to convert them to Option:

fn name<'t>(caps: &Captures<'t>, name: &str) -> Option<&'t str> {
    let s = caps.name(name);
    if s == "" { None } else { Some(s) }
}

Now, I don't know whether it would be better to modify at and name to return Option, or add new at_opt and name_opt functions. But at the very least, there should be some convenient way to distinguish between the cases "foo" and "foo;v=".

This would be relatively easy to implement, because Captures uses Option internally.

[BurntSushi]

I'm in favor of this. I think you make a good case for an Option type here.

I would vastly prefer changing the return types of existing functions instead of adding at_opt and name_opt. They increase the API needlessly IMO. The library is marked experimental so we don't have to worry about backwards compatibility. :-)

[BurntSushi]

@emk Do you want to take a crack at making the change? If not, I'm happy to do it.

[emk]

@BurntSushi Sorry, I got sidetracked running down other issues. But I was doing triage of my open Rust issues right now, and I saw this one again.

Do we need to deal with this change before 1.0? And are you still in favor of changing the existing name and at accessors to return Option? I think we should go ahead and do this, and I'd be happy to submit a patch.

[emk]

OK, I went ahead and implemented this as PR #19818. This is just one possible approach, of course—I'm not attached to the particular API.

Anyway, I did my best to make this mergable, but it's my first patch, so I've probably missed a lot of stuff. Once again, thank you for your guidance here!