On Wed, 19 Aug 2026 at 13:57 +0100, Jonathan Wakely wrote:
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.
Also, on the topic of "is this part of the standard API needed" ... is
it necessary for gcc::optional and gcc::expected to be
trivially-constructible and trivially-assignable when the
contained types are trivially constructible/assignable?
Maybe the answer's yes (so they can be memcpy'd into vec<> objects or
something?) but I thought it's worth asking, because if that part of
the API isn't required, the code could be simpified even further.
