Like std::path::PathBuf does, except the strings inside the container can be any valid strings.
One possible implementation is that the container uses 0xff as delimiter to separate string elements, since UTF-8 encoded strings do not contain 0xff byte.
Also, according to understanding, WTF-8 encoded OsStr also does not contain 0xff byte, so it is possible to have a container to store OsStrs.
typed-arena can also be used for this if you construct an Arena<u8>. In this case there are no delimiters OR indices; everything is in the pointers you receive from the arena. (however, you are extremely limited in how you can mutate them after they are created)
I think str_stack is a little too heavy, and one extra Vec doubles the size of the object. I don’t need random access to the elements. I could write one myself, but before dong that, I want to know if such a thing already exists.
I see, OsStr on Unix platforms uses [u8] instead of WTF-8 encoded slice. So container for OsStrs can not be done. But container for strings should still work.
Using String is not general enough since it cannot contain string "\0". slice-arena does not provide a container type that I can iterate through. I think I’ll have to do it my self.
If you have very specific requirements and don't want to pull a big crate, indeed it may be better to just DIY, since the core functionality takes less than 50 lines:
It is possible to make .get() and the indexing infallible at runtime, but that requires using generativity, which leads to a way more cumbersome API and is thus rarely worth it.