This makes it possible for the caller to provide their own ranking function for individual bytes. This can potentially speed up searches if one has a better guess than the default for the frequency distribution of bytes in a particular haystack.
There is a lot of ceremony here, and it basically boils down to supporting this in no-std no-alloc configurations. I was tempted to just require alloc for this sort of thing and ask for something like Arc<dyn Fn(u8) -> u8>, but that would require some ceremony of its own internally to deal with in the no-alloc case. And forcing an allocation for every searcher construction that uses a customer ranker feels like bad juju to me.
Another choice would be to just ask for a fn(u8) -> u8, but this makes the case of "I analyzed a haystack at runtime to build my ranker" more difficult. Not impossible. But annoying.
Yet another choice was to add the trait as in this commit, and then add it as a new type parameter to FinderBuilder. I believe this would work, but it requires complicating the public API even more and imposes constraints on the trait (for example, it would want to be Clone at least in order to avoid backwards incompatible changes in the FinderBuilder API). There's also just generally more ceremony with having to add a type parameter everywhere. Since we only need the ranking function at searcher construction time, we can ask for it at the time of construction and then get rid of it, thus avoiding it infecting everything else.
This makes it possible for the caller to provide their own ranking function for individual bytes. This can potentially speed up searches if one has a better guess than the default for the frequency distribution of bytes in a particular haystack.
There is a lot of ceremony here, and it basically boils down to supporting this in no-std no-alloc configurations. I was tempted to just require alloc for this sort of thing and ask for something like
Arc<dyn Fn(u8) -> u8>, but that would require some ceremony of its own internally to deal with in the no-alloc case. And forcing an allocation for every searcher construction that uses a customer ranker feels like bad juju to me.Another choice would be to just ask for a
fn(u8) -> u8, but this makes the case of "I analyzed a haystack at runtime to build my ranker" more difficult. Not impossible. But annoying.Yet another choice was to add the trait as in this commit, and then add it as a new type parameter to
FinderBuilder. I believe this would work, but it requires complicating the public API even more and imposes constraints on the trait (for example, it would want to beCloneat least in order to avoid backwards incompatible changes in theFinderBuilderAPI). There's also just generally more ceremony with having to add a type parameter everywhere. Since we only need the ranking function at searcher construction time, we can ask for it at the time of construction and then get rid of it, thus avoiding it infecting everything else.Fixes #117, Closes #118, Closes #119
cc @sentrip