You can also save on a ton of allocation if you reuse unleaked position slices on each match. It may also be nice to have a maxMatches argument that lets users set a limit, which would save on unnecessary allocation.
Wow! mind = blown. Please let me digest this code. I will merge later today. I'm probably going to come back and ask a few questions. I wouldn't want to pass up the opportunity to learn from you.
Thank you very much!
On a side note, working on this made me realize that case-insensitive comparison in Go is pretty inefficient, made a CL to improve it: https://go-review.googlesource.com/c/go/+/110018
Let me pull up some embarrassing numbers of fuzzy matching on all of Chromium.
Likely he rolled his own solution for the same reason that I did, he is targeting a specific type of names (file names for him) which comes with its own subset of rules that can be incorporated for better matching.
I haven't done any benchmarking to check the performance. Feedback welcome.
You should probably write some tests to ascertain that.
This library came out of a project I started. The project never saw the light of day. If I do see real world use, it'll be easier to find bugs and fix them :)
Can't we all just be happy that someone decided to write a fun project and made it freely available for others to learn from?