Hi all, just wanted to gather opinions on 2 changes I'd like to make to Boost.Nowide which go slightly above the initial goal: 1. Make detail implementations of widen/narrow public. - Mainly https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail/... which does templated conversion from/to wide strings which might be useful in generic contexts - But also the underlying UTF decoding/encoding templates initially extracted from Boost.Locale https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail/... I figured (and experienced) that those might be useful for consumers of Nowide as when they already use those UTF-8 APIs they might have other interface code which needs translation from/to wide strings, so exposing the existing code as a feature might make sense. Basically this would put them under boost::nowide::utf namespace instead of in the detail namespace. I guess I don't need to retain the old ones or put in forwarding headers, do I? 2. As requested and implemented over 2 PRs (last one still open: https://github.com/boostorg/nowide/pull/104) Large files are now supported by boost::nowide::filebuf (technically only used on Windows) but the implementation is pretty portable as e.g. Tests on Unix do use boost::nowide::filebuf. This is done by implementing ftell/fseek via _ftelli64/ftello and configure-time checking availability. As C++ is lacking C-Style file manipulation functions portably working with LFS I think a similar reasoning as above can be applied: It exists, it works and can be useful more generically so moving it out of the detail namespace might make sense. Opinions? Ideas? Regards, Alex PS: If anyone with filesystem experience would like to review #104 or at least glance over it, it would be appreciated.