# Making \`OsStr\` less opaque on Windows

**URL:** <https://internals.rust-lang.org/t/making-osstr-less-opaque-on-windows/16099>\
**Category:** libs\
**Created:** [February 9, 2022, 8:59pm UTC](https://internals.rust-lang.org/t/making-osstr-less-opaque-on-windows/16099 "2022-02-09T20:59:28Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\
**Post date:** [February 9, 2022, 10:31pm UTC](https://internals.rust-lang.org/t/making-osstr-less-opaque-on-windows/16099/5 "2022-02-09T22:31:57Z")

</div>

It's something I'd like to see too.

The problem is that if you work with `OsStr`, it's because you specifically care about preserving the broken surrogates, so all the functionality _has to_ support them losslessly. Otherwise you can call `to_string_lossy` to make all the problems disappear.

If you expose `impl Iterator<Item=Option<u8>>`, it's not materially different from `to_string_lossy`, you just get `None` instead of the replacement character.

Iterating over `Result<char, u16>` (I assume you've meant `char` here, not `u8`) is not especially useful, because with such iterator you can't do anything useful other than build a string, but given constraints, the only encoding you can use is WTF-8 or UCS-2, so you're back to square one.

* * *

I think `char_indices()` would be useful. It could iterate over `(usize, Option<char>)` (or `(usize, enum {char, u16})`). In such case you wouldn't iterate to keep the chars, but only to compare them and make a note of the indices for later slicing.

And of course it needs to support `get(range)`, `split_at()`, `splitn()`, etc.

---

_[View the full topic](https://internals.rust-lang.org/t/making-osstr-less-opaque-on-windows/16099)._