https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #5 from Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> --- > Status: SUSPENDED Well, coming from bug 95642, which has been marked as a duplicate of this bug, this is *very* disappointing. The C++17 standard absolutely clearly specifies that the constructor is overloaded for std::filesystem::path. libstdc++'s SFINAE implementation is incompatible because it fails for user-defined types that are implicitly convertible to std::filesystem::path. In order to at all be able to sensibly use libstdc++ std::filesystem::path in my codebase, I would have to put this awful work-around (making tons of assumptions about libstdc++'s enable_if expression) into my own type mpt::PathString: + // work-around for GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95642 / https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704 + mpt::PathString & make_preferred() + { + *this = mpt::PathString::FromFsPath(std::filesystem::path{path}.make_preferred()); + return *this; + } + mpt::PathString filename() const + { + return mpt::PathString::FromFsPath(std::filesystem::path{path}.filename()); + } + std::filesystem::path c_str() const + { + return std::filesystem::path{path}; + } and just pray and hope that libstdc++ will not change its non-conforming SFINAE-using implementation details to some other non-conforming implementation details in some future version. Can you guarantee, that you wont ever change your non-conforming SFINAE implementation whatsoever at all? If not, please just fix it. The standard is absolutely clear here. If you insist on doing something non-standard-conforming because of std::string_view, at the very least please do it for string_view only, without breaking behaviour for std::filesystem::path. Compatibility with std::experimental::filesystem::path can also be implemented without breaking the standard-specified std::filesystem::path overloads. The issue risen by https://cplusplus.github.io/LWG/issue3430 about the fear of implicit allocation is not convincing to me. std::basic_fstream accesses the filesystem, inducing all kinds of memory allocations, in-kernel blocking, and disk I/O. Some additional user space allocations just do not matter here. None of the call chain is specified noexcept either. While the issue of desiring std::string_view overloads itself appears reasonable to me, I fail to see why this issue should wait on that particular standard change. Even if std::string_view overloads existed, the current libstdc++ implementation would still be non-conforming for the std::filesystem::path overload and would need to be changed in exactly the same way as according to the current standard. The suggestion of forcing std::filesystem::path arguments to be exactly std::filesystem::path (i.e. making the current libstdc++ conforming by forcing the bug on everyone else) breaks backwards compatibility for other (currently conforming) implementations and IMO is also wrong on a higher level. There exist legitimate and semantically sound reasons to have user-defined types that are implicitly convertible to std::filesystem::path (std::filesystem::path's greedy behaviour of silently doing enconding conversions from char (which may be in locale encoding or utf8 in C++17, no way to tell) and thereby potentially losing data, being one of them, making it impossible to use it safely by itself). In the end, IMO std::filesystem::path should never have been implicitly convertible from a string in the first place. *This* is where the problems began. A string is not necessarily a path, which is why implicit conversion was/is wrong here. I doubt that will ever change by now, though, making it even more important to be able to wrap std::filesystem::path in an encoding-type-safe user-defined type. So, there are a couple of things wrong related to std::filesystem::path. The only way to sanely use it, is by strictly adhering to the agreed-upon standard. Delaying conformance with the standard until after some unrelated (to the std::filesystem::path overload) problems are resolved in the standard makes little sense to me, as it makes std::filesystem::path mostly unusable (without extremely ugly work-arounds) in the meantime (which could easily be multiple years) in code portable between different implementations. libstdc++ needs to get fixed as soon as possible. It is currently blocking progress in portable downstream users. After having said all this, I am not even sure anymore that this bug report here actually is a duplicate of my bug 95642. I am concerned about implicit conversion to std::filesystem::path not working, while this bug report is concerned about std::string_view not working. Please consider re-opening bug 95642.
