Peter Dimov wrote:
Beman Dawes wrote:
The default conversion is implementation defined, but users can supply their own conversion. One use case I have in mind is a character based O/S which uses some MBCS encoding of paths that isn't UTF-8, but the user wishes to burn a CD with UTF-8 encoding. The user should be able to provide such a conversion function, overriding the implementation defined default.
I see no need for custom conversions in this case. The user can just supply the appropriate narrow UTF-8 path directly. I also don't see where the implementation-defined default enters the picture, as the translation is between char and char.
I guess you have something like this in mind: void burn( wpath const & source, wpath const & dest ); where 'source' needs to be converted to a narrow path using encoding #1, but 'dest' needs to be converted to a narrow path using encoding #2 (UTF-8), _but_ the system doesn't know that so the user needs to override the conversion of 'dest'. Still makes no sense to me. :-) void burn( path const & source, path const & dest ); can be used to accomplish this, but it's a hypothetical scenario. If the system doesn't know that the CD needs its path UTF-8 encoded, nobody will be able to read that CD back! But I may be missing something. Perhaps if you illustrate the user path/conversion examples with code...
From where I sit, the library provides:
void fs_function( path const & p ); void fs_function( wpath const & p ); One of these is native, the other is either native or converts and calls the other. I can't "imbue" a custom conversion in path or wpath, but I don't have to, because I can just convert the path myself beforehand (with the exact same loss of portability). Turning the filesystem API into template<class Ch, class Tr> void fs_function( basic_path<Ch, Tr> const & p ); (thereby moving the entire implementation in headers) doesn't seem to buy us much; the native API is not, and will never be, templatized. :-) Not to mention that third-party libraries will be reluctant to adopt this style, as this requires them to ship source. In fact, many libraries will probably even omit the wpath overloads. If we could somehow combine path and wpath into one class, this would neatly sidestep this missing wpath overload problem. :-)