Implement intersection for two VersionReq

[Laegluin]

It would be useful to be able to merge to VersionReq into one that only matches Versions that both individual requirements match.

Something like this:

fn intersect_with(self, other: VersionReq) -> VersionReq

along with a version that takes an Iterator of VersionReq.

Considering that a VersionReq is only a Vec anyway, this should be fairly easy to implement. Unless somebody else wants it, I can do it.

[jonhoo]

@Laegluin Did you ever end up looking at this? It would come in super handy for rust-lang/cargo#8890.

[Laegluin]

@Laegluin Did you ever end up looking at this? It would come in super handy for rust-lang/cargo#8890.

For what I needed I simply hacked it together by parsing the all requirements again:

fn intersect(reqs: impl IntoIterator<Item = VersionReq>) -> VersionReq {
    let reqs: Vec<_> = reqs
        .into_iter()
        .filter_map(|req| {
            if req == VersionReq::any() {
                None
            } else {
                Some(req.to_string())
            }
        })
        .collect();

    if reqs.is_empty() {
        VersionReq::any()
    } else {
        reqs.join(", ").parse().unwrap()
    }
}

That's really ugly and probably not too fast but it works.

Implementing this properly would probably just require merging the two vecs in the range:
https://github.com/steveklabnik/semver/blob/051c39c50d565c597be65c4496597c7d16a514d9/src/version_req.rs#L34-L37).

I'm not quite sure how the Compat field affects this, I think that's a new addition that didn't exist when I opened the issue.

[jonhoo]

I feel like if we wanted "proper" support for this, we'd also look at the individual ranges and figure out where they overlap. That might produce significantly smaller requirements lists.

Separately, I've also really wanted the ability to take the union of requirements. I think the process for that will also be very similar...

[Laegluin]

I feel like if we wanted "proper" support for this, we'd also look at the individual ranges and figure out where they overlap. That might produce significantly smaller requirements lists.

Yeah, that would make a lot of sense, even though it's probably only worth it for the simple cases. In general all these types of features just come down to manipulating the list of ranges. I have to admit I am not particularly motivated to work on this at the moment, though.