[PATCH] libstdc++: implement P3052R2 view_interface::at()

[Jonathan Wakely]

On Fri, 18 Sept 2026 at 14:47, Yuao Ma <addr2line@gmail.com> wrote:
>
> On Fri, Sep 18, 2026 at 9:41 PM Tomasz Kaminski <tkaminsk@redhat.com> wrote:
> >
> >
> >
> > On Fri, Sep 18, 2026 at 3:28 PM Yuao Ma <addr2line@gmail.com> wrote:
> >>
> >> On Fri, Sep 18, 2026 at 9:15 PM Yuao Ma <addr2line@gmail.com> wrote:
> >> >
> >> > On Fri, Sep 18, 2026 at 12:33 AM Jonathan Wakely <jwakely@redhat.com> wrote:
> >> > >
> >> > > >From 7c8c3330f775b98949705fa33ee0605989254b65 Mon Sep 17 00:00:00 2001
> >> > > >From: Yuao Ma <c8ef@outlook.com>
> >> > > >Date: Thu, 17 Sep 2026 23:10:13 +0800
> >> > > >Subject: [PATCH] libstdc++: implement P3052R2 view_interface::at()
> >> > > >
> >> > > >libstdc++-v3/ChangeLog:
> >> > > >
> >> > > >       * include/bits/ranges_util.h (view_interface::at): Define.
> >> > > >       * include/bits/version.def: Define view_interface.
> >> > > >       * include/bits/version.h: Regenerate.
> >> > > >       * include/std/ranges: Define __glibcxx_want_view_interface.
> >> > > >       * testsuite/std/ranges/p3052.cc: New test.
> >> > >
> >> > > OK for trunk, thanks.
> >> > >
> >> > > >---
> >> > > > libstdc++-v3/include/bits/ranges_util.h    | 23 +++++++++
> >> > > > libstdc++-v3/include/bits/version.def      |  8 ++++
> >> > > > libstdc++-v3/include/bits/version.h        | 10 ++++
> >> > > > libstdc++-v3/include/std/ranges            |  1 +
> >> > > > libstdc++-v3/testsuite/std/ranges/p3052.cc | 55 ++++++++++++++++++++++
> >> > > > 5 files changed, 97 insertions(+)
> >> > > > create mode 100644 libstdc++-v3/testsuite/std/ranges/p3052.cc
> >> > > >
> >> > > >diff --git a/libstdc++-v3/include/bits/ranges_util.h b/libstdc++-v3/include/bits/ranges_util.h
> >> > > >index 423767f00fc..c14cdd7bd1e 100644
> >> > > >--- a/libstdc++-v3/include/bits/ranges_util.h
> >> > > >+++ b/libstdc++-v3/include/bits/ranges_util.h
> >> > > >@@ -38,6 +38,9 @@
> >> > > > #if __glibcxx_tuple_like // >= C++23
> >> > > > # include <bits/stl_pair.h> // __pair_like, __is_tuple_like_v
> >> > > > #endif
> >> > > >+#if __glibcxx_view_interface // >= C++29
> >> > > >+# include <bits/stdexcept_throw.h>
> >> >
> >> > Well this is a bit subtler than my original thought. This will cause a
> >> > include cycle:  <tuple> -> ranges_util.h -> stdexcept_throw.h ->
> >> > <string> -> memory_resource.h -> uses_allocator_args.h -> <tuple>.
> >> >
> >> > Includes # include <bits/stdexcept_throwfwd.h> can make the CI green,
> >> > but not sure whether it is ideal.
> >> >
> >> > see also: https://patchwork.sourceware.org/patch/144067
> >> >
> >>
> >> I did a little more digging, still can't find a more elegant way to
> >> break the cycle...
> >
> > If you do not come up with anything else, you could define views_interface::at
> > out of line in <ranges> header, and only forward declare in ranges_util.h
>
> Is it possible to rework r13-5338-g33ed11085837e9, create a header
> like bits/subrange_fwd.h so that we can avoid including the whole
> ranges_util.h in <ranges>?

Do you mean in <tuple>? It's all needed in <ranges>, right?

I think it would be an improvement if <tuple> only sees the
declarations of subrange and its tuple_size and tuple_element
specializations.

>Not sure which approach is better, but I
> think it is better to keep _at_ and _operator[]_ alike.
>
> And for the simplest approach, is include <bits/stdexcept_throwfwd.h>
> directly acceptable?

I think that's acceptable, but don't you need the full definitions of
the __throw_xxx functions to use view_interface::at during constant
evaluation?