https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
--- Comment #8 from Jörn Heusipp <manx-bugzilla at problemloesungsmaschine dot de> --- (In reply to Jonathan Wakely from comment #6) > (In reply to Jörn Heusipp from comment #5) > > 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. I'd rather not use std::filesystem whatsoever at all than polluting the whole code base with redundant explicit conversions. This is exactly what I am trying to avoid here in the first place by implementing implicit conversion (which the standard allows me to do). Your implementation breaks this, because you decided to disregard the standard in order to break string_view conversions. If you want to break string_view, break it. But please do so selectively and do not break other implicit conversions at the same time. There is no reason to. This is just sad. > > 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. The intended design of std::basic_fstream::basic_fstream(const filesystem::path& s, ios_base::openmode mode = ios_base::in | ios_base::out); (literally from the standard) is unambiguously clear to me. I am allowed to provide types which are implicitly convertible (as long as no other implicit conversion causes ambiguity with other overloads). Again, this is IMO unrelated to whatever the intention for std::string_view might or might not have been. The fact that they rely on the same overload is coincidence. Are you arguing that no user-defined type should ever be implicitly convertible to std::filesystem::path? If so, can you provide reasoning?
