Re: [boost] [chrono/date] year/day/week literals

Subject: Re: [boost] [chrono/date] year/day/week literals
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2013-05-04 15:30:55

On May 4, 2013, at 2:38 PM, Anders Dalvander <boost_at_[hidden]> wrote:

> 
> On 2013-05-03 12:01, Vicente J. Botet Escriba wrote:
>> Hi,
>> 
>> on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction.
>> Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous.
>> Everyone agree with the constant object for month.
>> 
>>  date dt(year(2013), may, day(3));
>> 
>> But having to use day(3) or year(2013) seems to wordy.
>> 
>> I was wondering if we can not add some literals for day, year and week so that we can just write
>> 
>> date dt(2013y, may, 3d);
>> 
>> The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
>> 
>> What do you think?
>> 
>> Vicente
>> 
> 
> Do people actually hard code dates as often to make this necessary?
> 
> We don't need to do something just because we can, we should do something that is useful and have a real life use case.

It doesn't seem like a stretch to me for an application, especially one about past events, to want to hard-code dates of historical significance.  With today's technology, they can already hard-code them in a ymd format.  It doesn't much of stretch to imagine that there could be a reason they might want to put them into rom as a serialized date.  E.g. perhaps that would optimize the lookup of the date to find the associated historical significance.

If constexpr'izing dates was exceptionally difficult, then perhaps the benefit wouldn't be worth the cost.  However I've already implemented such constexpr computations using C++11, and yes it was somewhat of a pain.  However it now appears that a significant subset of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3597.html has been accepted into the C++14 working draft, which will make constexpr'izing these computations trivial.

The acceptance of this new language feature, imho, firmly adjusts the benefit/cost ratio up to an attractive level, especially since C++14 has also already constexpr'ed system_clock::time_point:  the existing (but not yet fully exploited) serial representation of a modern date_time type.

Howard