On Wed, 19 Aug 2026 at 13:18, Arsen Arsenović <[email protected]> wrote: > > [Trying again, this time correctly spelling 'libstdc++' in CC.] > > Jakub Jelinek <[email protected]> writes: > > > Please put it into gcc/ directly then. > > I really dislike other subdirs with extremely few files, it is significant > > inbalance having directories for almost nothing vs. the 1000+ files > > directory, e.g. the gcc/topics/ directory containing a single header, or > > gcc/custom-sarif-properties/ which has 6 files in it or > > gcc/sym-exec/ with 7 files in it. All those would be better in gcc/ > > directly, custom-sarif-properties with some file prefixes, sym-exec as is. > > Sure, that's OK with me, but note that Jason suggested giving them their > own directory because they're pulled in from elsewhere > (https://github.com/TartanLlama/expected and > https://github.com/TartanLlama/optional, which place them in 'tl/'; we > could also place a copy of the CC0 in there). > > Of course, that's an obsolete consideration if we reuse the libstdc++ > implementation. > > > And yes, I'd think we should based it on libstdc++ implemenntation > > rather than some third party (sure, some tweaks will be needed, we > > need to work with any C++14 implementation, so stop relying on stuff > > from <bits/c++config>). > > > > Also, I'd say we should use <expected>/<optional> directly when being > > compiled with C++23 resp. C++17, only use the extra headers as > > fallback for older C++ compilation, so that when we eventually bump > > minimum C++ version to C++17 (or much later to C++23), we can remove > > those headers. > > Yes, I agree. > > Jonathan, what do you think about reusing <optional> and <expected> in > gcc/? (with the goal of eventually removing them) > > That'd mean they need to be modified to work with any C++14 compiler. > > Given that this is temporary, I imagine just maintaining the two > implementations separately might be okay, but I also imagine that the > temporary period will be of ~10 years for <expected> at least.
I think they should definitely be maintained separately, otherwise the headers in libstdc++ would need to be untangled from things like constexpr exceptions and std::format, which aren't needed for the copies used by gcc. There's a lot more than just <bits/c++config.h> that they depend on. N.B. we have <experimental/optional> which already supports C++14 but it might be simpler to start from <optional> and cut bits out, to ensure you have the correct std::optional API not the older std::experimental::optional API. I don't think there's anything in std::optional that won't work in C++14 except for being fully constexpr, but it's OK for gcc if it's not fully constexpr. Although the code uses C++20 concepts, there are fallback implementations used for C++17 mode and those should work in C++14 too. std::expected will be harder, because that was written using concepts from day one, so there is no pre-C++20 fallback implementation. > > I think that the Rust FE should be able to switch to using the libstdc++ > implementation quite easily, too, since the current implementation is > meant to be compatible with the standard one. > -- > Arsen Arsenović
