On Fri, 23 May 2025 at 14:30, Andrey Gorbachev via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi all,
>
> Is std::chrono::sys_days sufficiently "like an integer" for iota to work with it?
>
> I understand that the current standard would not allow it (concept weakly_incrementable I guess stops it), but should it allow it?

This is an interesting idea. I think what makes time_point not satisfy
weakly_incremental is that it doesn't have a difference_type member,
and that the result of its operator- is not an integral type. If we
did specialize incrementable_traits<sys_time<D>> then it still
wouldn't satisfy weakly_incrementable because its difference type is D
which is a duration, which is not integer-like.

So I think we'd need to make significant changes to iota_view (or
maybe weakly_incrementable) to support arbitrary "incrementable but
not a number or an iterator" types.

> It would be good to be able to do something like:
>
> const auto value = std::chrono::sys_days{ /*some date*/ };
> const auto bound = std::chrono::sys_days{ /*some later date*/ };
> auto s =
> std::views::iota(value, bound) |
> std::views::filter(my::is_business_day);
>
>
> To generate business days, etc between 2 calendar dates.
>
> Or is iota really, really just integers? We can of course in this case (sticking with iota), do something like:
>
> const auto value = std::chrono::sys_days{ /*some date*/ }.time_since_epoch().count();
> const auto bound = std::chrono::sys_days{ /*some later date*/ }.time_since_epoch().count();
> const auto to_sd = [](const int i)
> {
> return std::chrono::sys_days{} + std::chrono::days{ i };
> };
> auto s =
> std::views::iota(value, bound) |
> std::views::transform(to_sd) |
> std::views::filter(my::is_business_day);


This workaround doesn't seem too bad to me, you could wrap the
iota|transform pipeline into a function that returns that view, and
then does it really matter whether what you have is an iota view or
not? You have the functionality you're looking for, without changing
iota_view or chrono:

template<typename Dur> requires std::weakly_incrementable<typename Dur::rep>
constexpr auto
sys_time_iota(std::chrono::sys_time<Dur> from,
              std::chrono::sys_time<Dur> to)
{
  return std::views::iota(from.time_since_epoch().count(),
                          to.time_since_epoch().count())
    | std::views::transform([](Dur::rep r) {
      return std::chrono::sys_time<Dur>(Dur(r));
    });
}

You could overload it for (start, count) instead of (start,end):

template<typename Dur> requires std::weakly_incrementable<typename Dur::rep>
constexpr auto
sys_time_iota(std::chrono::sys_time<Dur> from,
              Dur::rep n = Dur::max().count())
{
  return std::views::iota(from.time_since_epoch().count(),
                          from.time_since_epoch().count()+n)
    | std::views::transform([](Dur::rep r) {
      return std::chrono::sys_time<Dur>(Dur(r));
    });
}

And you could turn that into a range adaptor if you wanted, although I
don't see an immediate use for this in the middle of a pipeline.

> It feels to me that the current standard is unnecessarily too restrictive in this case and could be relaxed.

It feels to me that the current standard is already flexible enough to
support this :-)