Ed Page

> Also this idea should be expanded to Cargos other outputs. Should that be done here, or in some other existing crate, or in some new Cargo Team maintained crate?...

Was not aware of that unstable feature, thanks! I can understand the challenge of stablizing it.

> Now that bstr has an 'alloc' feature, we need to rethink how we setup the serde feature flags. Previously, all we had was 'std' and 'no std'. But now...

Speaking of > ByteVec::into_os_string now returns Result instead of Result. In the docs, it says > 1. One could re-implement WTF-8 and re-encode file paths on Windows to WTF-8 by...

As a usability note, I wrote an application with `BStr` in the internal APis and kept getting tripped up that I needed `as_bstr()` or `.map(ByteSlice::as_bstr)` at the end of any...

From https://github.com/BurntSushi/bstr/issues/40#issuecomment-1180788604: > Right yeah. That's what bstr 0.1 was: https://docs.rs/bstr/0.1.4/bstr/

From https://github.com/BurntSushi/bstr/issues/40#issuecomment-1181036333: > @epage See #5 and #8 for more details on why `bstr 0.1 -> 0.2` went from concrete `BString`/`BStr` types to extension traits on `Vec`/`[u8]`. It is slightly...

Looking over #5, it seems the main reasons for the switch are: - More universal interop since existing APIs work with `&[u8]` / `Vec` - Encouraging use of `&[u8]` /...

I suspect we could make the trait reference `Self` and a borrowed version of `Self` to allow the `u8` version to work with more `u8`s and the `BStr` version to...

Fully understandable > The issue of whether to bring the BString/BStr types themselves into std is a thorny one. It is "yet another string type," for example. Agreed and have...