Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-03 09:30:27

Le 03/05/13 13:52, Rob Stewart a écrit :
> On May 3, 2013, at 3:47 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>
>>> You can even handle other orders that way:
>>>
>>> date(month, unsigned, year);
>>> date(month, day, unsigned);
>>> date(unsigned, day, month);
>>> date(year, unsigned, month);
>>>
>>> One can also be explicit for both day and year:
>>>
>>> date(year, month, day);
>>> date(month, day, year);
>>> date(day, month, year);
>>> date(day, year, month);
>> I don't think that the constructor should support different orderings.
> It could, easily, so why not? Different locales have different preferred orderings. All can learn to use the descending magnitude order, but a little flexibility, without ambiguity, would be nice.
>
>>> I'm assuming explicit constructors for day and year, of course.
>> Of course. And implicit conversion to his representation, so that
>>
>>   date(2013, may, 3, no_check)
>>
>> is yet valid.
> That's where I disagree. If you have explicit constructors for year and day, and no constructor accepting two ::rep arguments, then your example won't compile.
>
> That's also what enables support for other argument orders.
The no_check constructor allows only year,month,day order of arguments. 
If the user know that the date is valid it can know the order. This is a 
low level function.
>
>> We could have a factory make_date function that doesn't checks the validity of the date and avoids the no_check parameter
>>
>>   make_ymd_date(2013, may, 3)
> I don't understand what no_check has to do with such a function. Add an overload that accepts no_check_t to get that.
>
>
The name is not the good one.

  make_unchecked_date(2013, may, 3);
or

  make_valid_date(2013, may, 3);

Vicente