https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Jörn Heusipp from comment #5) > > 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. And also for string_view, because that's convertible to filesystem::path, and that is the topic of the issue reported against the standard. > 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: Or you can just convert it to filesystem::path explicitly before passing it to fstream members. > 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. Or just convert to filesystem::path explicitly. > 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. The standard is flawed and no longer follows its own design. I want to get some clarity about the intended design. > 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. They're exactly the same. string_view is expected to work by converting to filesystem::path, which is the same as your type.
