Feature request: year_month_weekday operator+(days)

[howardhinnant]

Feature request: year_month_weekday operator+(days)

[HowardHinnant]

This library is meant to be a foundational library upon which you can efficiently build higher-level date libraries (like tz.h). A core component of this library is that it makes expensive computations explicit, so that you can see where they are in your code. Higher-level code can hide these expensive/explicit operations as desired.

Cutting your example down a bit, your meeting computation (the day after the 3rd Tuesday of the month) looks like:

date::year_month_day
meeting1()
{
    namespace d = date;
    auto today = d::year_month_day{ d::floor< d::days >( std::chrono::system_clock::now() ) };
    auto hackDay = d::tue[ 3 ]/today.month()/today.year();
    return d::year_month_day{ d::day_point( hackDay ) + d::days{ 1 } };
}

This looks pretty good to me. I wouldn't personally use hackDay as a variable name, but I'm not here to lecture in that department. Here is another way to compute the same day. It is about as much verbosity, and also about the same expense:

date::year_month_day
meeting2()
{
    namespace d = date;
    auto today = d::year_month_day{ d::floor< d::days >( std::chrono::system_clock::now() ) };
    auto hackDay = d::year_month_day{d::tue[ 3 ]/today.month()/today.year()};
    return hackDay.year()/hackDay.month()/(hackDay.day()+d::days{1});
}

The computation on the day field in this latter example is known to be safe as the 3rd Tuesday of the month never falls on the last day of the month. But it hasn't gained you anything (unless you like the readability better, which is a subjective point).

If we were to define day arithmetic on the year_month_weekday type, then to be generally correct, the operation would have to internally convert to day_point, do the arithmetic, and then convert back to year_month_weekday. We would save a line of code:

date::year_month_day
meeting3()
{
    namespace d = date;
    auto today = d::year_month_day{ d::floor< d::days >( std::chrono::system_clock::now() ) };
    return d::year_month_day{d::tue[ 3 ]/today.month()/today.year() + d::days{1}};
}

But we would not make the code any more efficient. Indeed, it might actually make the code less efficient. This would lend itself to inefficient programming. For example, following this logic we should put push_front on vector and operator[] on list. Both are easily done. But both make expensive operations look cheap to the programmer.

Feature request rejected. However this is a good question that others will ask, so leaving this open to help others find this rationale. Thank you for using this library, and for your feedback.

[paulbendixen]

Very well
I was trying to use your library after seeing your CPPCON talk, and it just seemed to be more awkward to use than what you showed, so I thought it might be me that had overlooked something, or it really was missing.
The argument about exposing costly functions is very appreciated.
BTW. The day before our meeting is when the hacker space most regularly convene, so the variable name hackDay is actually meant quite literally :)
Fine by me to keep it open, thanks for supplying the library and for the feedback on using it.

[rbock]

Very nice example.

I wonder if it would make sense to add a section "Non-features and their rationale" or something like that to the documentation rather than keeping issues open?

[HowardHinnant]

This point is mentioned under "Efficiency" here: http://howardhinnant.github.io/date_v2.html . However clearly this is somewhat hard to find. More organized documentation is always a plus. Perhaps the wiki would be a good place to put something like this: https://github.com/HowardHinnant/date/wiki.

[HowardHinnant]

Finally got around to writing this up: https://github.com/HowardHinnant/date/wiki/FAQ#day_arithmetic

[HowardHinnant]

Closing with the issue documented in the wiki per my previous comment.