On Mon, Jun 12, 2017 at 1:14 PM, Groke, Paul via Boost < boost@lists.boost.org> wrote:
Since the UTF-8 conversion is only done on/for Windows, and Windows doesn't guarantee that all wchar_t paths (or strings in general) will always be valid UTF-16, wouldn't it make more sense to just *define* that the library always uses WTF-8, which allows round-tripping of all possible 16 bit strings? If it's documented that way it shouldn't matter. Especially since users of the library cannot rely on the strings being in UTF-8 anyway, at least not in portable applications.
I agree that round-tripping to wchar_t paths on Windows is very important. I also agree that not detecting invalid UTF-8, or failing to produce an error in such a case, is very important to *avoid*. Can we get both? Is it possible to add a WTF-8 mode, perhaps only used in user-selectable string processing cases? Zach