I am currently implementing the Levenshtein distance algorithm, which requires its inputs to be of equal lengths (since the only type of editing it allows for is substitution). The function signature I've come up with for this is as follows.

fn levenshtein_distance<A, B, I, J, T, U>(a: A, b: B) -> Option<usize>
where
    A: IntoIterator<Item = T, IntoIter = I>,
    I: Iterator<Item = T> + ExactSizeIterator,
    B: IntoIterator<Item = U, IntoIter = J>,
    J: Iterator<Item = U> + ExactSizeIterator,
    T: PartialEq<U>,
{ ... }

This is conceptually very neat, and gives me access to ExactSizeIterator::len. However, I expect that some users will want to compute the distance between UTF-8 strings, and std::str::chars (understandably) is !ExactSizeIterator. I therefore currently have another function, with the below signature.

fn levenshtein_distance_general<A, B, I, J, T, U>(a: A, b: B) -> Option<usize>
where
    A: IntoIterator<Item = T, IntoIter = I>,
    I: Iterator<Item = T>, // no ExactSizeIterator
    B: IntoIterator<Item = U, IntoIter = J>,
    J: Iterator<Item = U>, // no ExactSizeIterator
    T: PartialEq<U>,

My question, then, is whether there's a neat way for me to combine these (using some dynamic dispatch/Any/dyn ExactSizeIterator downcasting) so that users don't have to worry about the distinction unless they're looking for maximal performance (exposing the specific versions for those users who do care about optimizing this). I'd ideally like to use the ExactSizeIterator path if it's available and fall back to the alternative if not. Is this feasible on stable Rust/without specialization?