Struct RouteMatchView 

#[non_exhaustive]
pub struct RouteMatchView {
    pub matched: Option<MatchedRule>,
    pub considered: Vec<MatchConsidered>,
}

Shown to the user when they ask “what rule would match this request?”.

Why we carry both the match and the non-matches

A GUI debugger doesn’t just answer “which rule matched” — it answers “why didn’t the rule I expected match?”. Surfacing the mismatches lets the UI highlight the first failing predicate on each rule.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

matched: Option<MatchedRule>

Matching rule, if any. None means the request would fall through to the dynamic-route fallback.

considered: Vec<MatchConsidered>

Every rule the matcher considered before deciding, with the reason it was skipped. Order matches evaluation order.

Trait Implementations

impl Clone for RouteMatchView

fn clone(&self) -> RouteMatchView

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for RouteMatchView

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Serialize for RouteMatchView

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.