Re: [PATCH gcc/* 1/2] gcc: copy expected and optional out of rust/utils

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ć