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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-03 21:30:42

On May 3, 2013, at 9:30 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> 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.

I'm talking of possibilities, not about an existing design. In the US, we write dates in a way that everyone else thinks is weird: month/day/year. A constructor taking three integral arguments will be a stumbling block for US users. We can, of course, learn the right order, but I guarantee that many -- me, certainly -- will find it necessary to consult the docs every time, if there's more than a fortnight between uses of that constructor. Even if it were validated, not all misuses can be detected.

Using typed arguments, despite the added verbosity, solves that, though probably at the expense of all of those who only think of YMD order. That's also why I suggested all of the constructor possibilities above.

>>> 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);

make_date(year(2013), may, 3) works just as well and can be overloaded for other orders.

You could add overloads that take no_check_t (or, maybe, unvalidated_t), or just create a similar set of overloads of your make_unvalidate_date().

___
Rob

(Sent from my portable computation engine)