Day 2 afternoon: prefix_matches - solution bug

[Traf333]

Hi guys, thanks for awesome book you've provided. Really well detailed and help me to pick this language on board easily.

I've just found that solution example might not work correctly with some edge cases like

assert!(prefix_matches(
        "/v1/publishers/*/books",
        "/v1/publishers/foo/bar/baz/books"
    ));

so, probably match pattern should consider that wildcard might be more than one step, what do you think?

The example below will resolve this issue, but probably might have include some non-best practices as I've just recently met this language

pub fn prefix_matches(prefix: &str, request_path: &str) -> bool {
    let a: Vec<&str> = prefix.split('/').collect();
    let b: Vec<&str> = request_path.split('/').collect();

    for (i, pattern) in a.iter().enumerate() {
        let is_wild = pattern.contains('*');

        if is_wild {
            let rest = a[i + 1];
            return b[i..].iter().any(|p| p == &rest);
        }

        if a.get(i) != b.get(i) {
            return false;
        }
    }

    true
}

[mgeisler]

Hi @Traf333,

Thanks for the kind words!

I've just found that solution example might not work correctly with some edge cases like

assert!(prefix_matches(
        "/v1/publishers/*/books",
        "/v1/publishers/foo/bar/baz/books"
    ));

so, probably match pattern should consider that wildcard might be more than one step, what do you think?

Actually, this is not supposed to match — the idea of the wildcard is that it only matches a single "segment" and a "segment" is the text between two / characters.

In your code, I suppose a[i + 1] could result in a panic if the i is equal to a.len()-1? Or is there some reason why we cannot reach that index?