[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 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ć
signature.asc
Description: PGP signature
