[Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming

[manx-bugzilla at problemloesungsmaschine dot de]

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.