Subject: Re: [boost] [chrono/date] Unit specifiers arithmetic
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2013-05-06 11:06:11
On May 6, 2013, at 10:42 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
> 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.
A poor reason to create a poor design. A design that would be in direct conflict with the std::chrono library:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm#duration
> Is it possible for the user to pass a duration to a function with the units being ambiguous?
Howard