Re: [boost] [chrono/date] Unit specifiers arithmetic

Subject: Re: [boost] [chrono/date] Unit specifiers arithmetic
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-06 10:42:51

Le 06/05/13 16:10, Howard Hinnant a écrit :
> On May 6, 2013, at 9:55 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>
>> Le 06/05/13 15:34, Howard Hinnant a écrit :
>>> On May 6, 2013, at 6:31 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>>>
>>>> Hi,
>>>>
>>>> Moving from checked dates to unchecked ones by default and forcing to user the Unit specifiers year/month/day in any date constructor (even the unchecked ones) has some ugly consequences. Note that I was able to build an unchecked date as
>>>>
>>>> date d(2013,5,6, no_check);
>>>>
>>>> Given
>>>>
>>>>   year y;
>>>> month m;
>>>>   day d;
>>>>
>>>> the following will not compile now as the constructors expects a year but y+1 is an int.
>>>>
>>>>   date d(y+1, m, d);
>>>>
>>>> The user needs to type
>>>>
>>>>   date d(year(y+1), m, d);
>>>>
>>>> Is this what we want to provide to the user or should we add basic arithmetic on these unit specifiers?
>>> This is an example of where flexible ordering and implicit last unit starts to shine.  Examples from my 2011 paper:
>>>
>>>          start = mon <= jan4/(d.year()-1);
>>>
>>>          date next_start = mon <= jan4/(start.year()+1);
>>>
>>> Or translated to your example and syntax:
>>>
>>>      date d(d, m, y+1);  // works because last unit can be int
>> Last unit or any unit but only one?
> Any two explicit units should disambiguate.  We could even take it more lax than that and still avoid ambiguity if desired.
>
> A warning though:  We want to make the checked syntax more attractive than the unchecked syntax, else all dates will be unnecessarily unchecked in practice.
>
Agreed. But some (in particular N3344) are requesting this prototype :(

   date(int,int,int);

I suspect they would not adhere to the named parameters.

Vicente