> > Ah yes, that's a problem. If you create > views::indices(ranges::distance(views::iota(0ULL, 1ULL))) then you > need to create an iota_view of the difference type of iota(0ULL, > 1ULL), but that can't be represented. You would need an integer-like > type wider than our widest integer-like type.
> That might be a defect in the wording for views::indices, but that's > not your concern. There's no need to test it with that type then. Yep, it seems like indices(*integer-class-type*(0)) will always fail. We probably should fix the wording to only require a non-bool integral type. Jonathan Wakely <[email protected]> 於 2025年10月15日 週三 上午12:21寫道： > On Tue, 14 Oct 2025 at 17:08, Yuao Ma <[email protected]> wrote: > > > > Hi Hewill and Jonathan, > > > > On Tue, Oct 14, 2025 at 11:39 PM Hewill Kang <[email protected]> wrote: > > > > > > 1. The prefix ranges:: in ranges::__detail::__is_integer_like can be > removed. > > > > It can't. views has its own __detail namespace. > > > > > 2. Parameters should not be passed by reference; otherwise, const int > i = 0; std::views::indices(i); will fail because const int& does not > satisfy __is_integer_like. > > > > Yes I figure that out with the new testcase. Done. > > > > > 3. operator() can be static. > > > > I think I'll stick to the style of the existing functions. > > static operator() is a C++23 feature, so wasn't an option for the > original C++20 views. > > I'm not sure it makes much difference on the ABI used for most of our > supported targets, and it should be optimized away anyway. In fact, we > could add [[__gnu__::__always_inline__]] to the operator() here, since > it's incredibly simple. > > > > The testcase got updated, testing against different type and size. But > > ranges::__detail::max_{size, diff}_type not working here: > > Ah yes, that's a problem. If you create > views::indices(ranges::distance(views::iota(0ULL, 1ULL))) then you > need to create an iota_view of the difference type of iota(0ULL, > 1ULL), but that can't be represented. You would need an integer-like > type wider than our widest integer-like type. > > That might be a defect in the wording for views::indices, but that's > not your concern. There's no need to test it with that type then. > >
