> > Yes, because the standard says "The width of an integer-class type is > greater than that of every integral type of the same signedness." So > implementations can't even have other integer-class types which are > not wider than their widest integral type, e.g. no 4-bit integer-class > type, or a 12-bit one.
I'm coming at this purely from a constraint perspective. The iota_view<W, Bound> requires W to model weakly_incrementable, which is never true for integer-class types because integer-class types do not have a valid iter_difference_t (because incrementable_traits<integer-class type> is not valid). Therefore, iota_view's W is never an integer-class type. Only Bound can be an integer-class type. However, when Bound is an integer-class type, it only serves as a sentinel, because we only care about its ability to be compared with W. Although the wording of iota_view seems to expect that W might be of type integer-class type, it never is (because the constraint is not satisfied). The only invalid spelling I can think of is views::iota(0, max_diff_type(0)). But that doesn't make much sense, and no user would want to write it that way IMO. Jonathan Wakely <[email protected]> 於 2025年10月15日 週三 上午12:46寫道： > On Tue, 14 Oct 2025 at 17:34, Hewill Kang <[email protected]> wrote: > >> > >> 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. > > Yes, because the standard says "The width of an integer-class type is > greater than that of every integral type of the same signedness." So > implementations can't even have other integer-class types which are > not wider than their widest integral type, e.g. no 4-bit integer-class > type, or a 12-bit one. > > > We probably should fix the wording to only require a non-bool integral > type. > > Yes, I think so. Otherwise it implies that you should be able to use > integer-class types, even though it can never work. > >
