On 24 October 2025 14:27:23 CEST, Jonathan Wakely <[email protected]> wrote:
>On Fri, 24 Oct 2025 at 13:11, Matthias Kretz <[email protected]> wrote:
>>
>> Matthias Kretz [Friday, 24 October 2025, 14:04:16 CEST]:
>> > > > > #endif // __glibcxx_integer_sequence
>> > > >
>> > > > This is defined for C++14 and later, but I think it can't actually be
>> > > > used for anything useful without C++26 packs introduced by structured
>> > > > bindings, right?
>> > > >
>> > > > I wonder if we want to restrict the definition of _IndexPack to C++26?
>> > >
>> > > I have defined my inital patch under #if __cpp_structured_bindings >=
>> > > 202411L,
>> > > i.e. auto [...ids] = is supported by the compiler, and I think this is
>> > > the
>> > > right condition.
>> > > If this functionality will be made available as extension in previous
>> > > standard, _IndexPack
>> > > will also be useful.
>> >
>> > My thinking was that this simple tool itself doesn't require C++26. You can
>> > also use it like this:
>> >
>> > for (int i : _IndexPack<10>) { ... }
>>
>> That said, it's incorrectly named. It really is an iota object or an index
>> array. So _Iota<N> or _IndexArray<N>?
>
>Good point. I do quote like _Iota, but there's too much potential for
>confusion with the other iotas we have (std::iota algo,
>ranges::iota_view, views::iota). Maybe _IotaArray would be
>disambiguate it, but _IndexArray works too.
_IotaArray is very clear IMHO. I'll go with that.
My P3319 proposed std::iota_v<T[N]>. But so far LEWG found it unmotivated. A
std::__iota_v should probably use the same syntax as what I proposed. I
wouldn't use that name unless it becomes part of C++29 and we want to have it
for earlier standards.
> We could guard it with __cpp_structured_bindings >=
>202411L for now, and change it later if we have uses for it in
>pre-C++26 code.
👍
