So far, in my limited testing, I haven't been able to 'break' this.
If we do break it, and decide we can't use unsafe here, maybe look into simdutf8.
It may be the case that since we only perform inserts/searches with UTF-8 strings, that this cannot break.
It may only be safe for well-formed URI paths, e.g. if you accidently insert a path with the query attached, it may not longer be safe? Maybe add some additional checks to the insert process if thats the case.
If we prove this is safe, add some SAFETY comments.
UPDATE: Yes, easily breakable. Might only be the value that can have safety issues, however. Let's patch this up!
Only annoying thing is now we need our search method to return a Result<Option<_>>. Unless we move the check to the Path creation?
So far, in my limited testing, I haven't been able to 'break' this. If we do break it, and decide we can't use unsafe here, maybe look into
simdutf8
.It may be the case that since we only perform inserts/searches with UTF-8 strings, that this cannot break.
It may only be safe for well-formed URI paths, e.g. if you accidently insert a path with the query attached, it may not longer be safe? Maybe add some additional checks to the insert process if thats the case.
If we prove this is safe, add some SAFETY comments.
UPDATE: Yes, easily breakable. Might only be the
value
that can have safety issues, however. Let's patch this up!Only annoying thing is now we need our search method to return a
Result<Option<_>>
. Unless we move the check to thePath
creation?