The point of OsStr is to abstract over a platform specific representation. Internally, on Windows, that representation is WTF-8 while on Unix it’s just a sequence of bytes. Those internal representations aren’t part of the public interface of OsStr. However, if you can make an assumption about your platform, then you can access the raw bytes. A similar interface exists on Windows, but unlike Unix, access to it is not free: the internal WTF-8 representation is transcoded to/from potentially ill-formed UTF-16.
So, I think the answer to your question is, “yes, right now, you really do need to write separate functions, and your Windows function will have an additional cost.”
I suppose the proper answer here is that the OsStr APIs should be expanded to support typical search/split/whatever operations one might find on &str. In particular, to satisfy the general case, your needle needs to be an OsStr.
If you can make assumptions and you can afford it, like, your needle is always a &str, then you could convert your path element to UTF-8 first and then search.
Yes, I’d love for there to be some common functionality in the OsStr world.
I don’t want to assume unicode, or pay the cost for conversion to/from unicode (so str is right out), but would like to have some simple operations on OsStr such as comparison of prefix/suffix relationships. I believe it is always either &[u8] or &[u16] so there shouldn’t be any problem making such comparisons.
To be clear, an &OsStr is always a &[u8]. The key platform distinction is the encoding of that &[u8]. On Unix, it’s just arbitrary bytes. On Windows, it’s WTF-8, which is basically UTF-8 w/ surrogates. You only get &[u16] after an explicit transcoding step.
What that means is that all of the search routines need to be aware of WTF-8, which I think seems OK, although I haven’t given it much thought.