From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1D781386F033; Mon, 10 Aug 2020 16:46:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D781386F033 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1597077996; bh=oZuavaZ5ngmcA3xoUedr5DTOcrNLJZuY3VT+r1LADEA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CG/hIjZZMSoAulwVS8YxrsjsRq2jc8XhHSHCX2AS7SDCM+pjeUwYaUmsDJRTXxKgl 0Rf4zoAR5lykPE5tJvOMYAbTRg5qKGiFsWMPu5yy7U4T92dMSPPcituEDk3GVpoaLM BIG65r8aluBVfCrwSLTJvb8Ofsy1YwpHs67N/osI= From: "manx-bugzilla at problemloesungsmaschine dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/90704] [LWG 3430] filesystem::path overloads for file streams are not conforming Date: Mon, 10 Aug 2020 16:46:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manx-bugzilla at problemloesungsmaschine dot de X-Bugzilla-Status: SUSPENDED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 16:46:36 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90704 --- Comment #5 from J=C3=B6rn Heusipp --- > Status: SUSPENDED Well, coming from bug 95642, which has been marked as a duplicate of this b= ug, 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=3D95642 / https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D90704 + mpt::PathString & make_preferred() + { + *this =3D 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};=20=20=20=20=20 + } and just pray and hope that libstdc++ will not change its non-conforming SFINAE-using implementation details to some other non-conforming implementa= tion 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, with= out 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, a= nd disk I/O. Some additional user space allocations just do not matter here. N= one 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 particul= ar 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 forc= ing the bug on everyone else) breaks backwards compatibility for other (current= ly 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 m= ay be in locale encoding or utf8 in C++17, no way to tell) and thereby potenti= ally 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 stand= ard. 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 (with= out 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.=