Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-04 03:29:46
Le 04/05/13 03:30, Rob Stewart a écrit :
> 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.
>
I understand your concern.
There are some that are requesting a constructor as simple as
date(int y, int m, int d);
that presumes the values given stand for a valid date.
Others want the C++ type system helps them as much as possible.
Would the following be enough satisfactory
Taking in account only the ymd constructors
// date validaty check
date(year, month, day);
date(year, month, int);
date(year, int, day);
date(int, month, day);
// no date validity check
date(year, month, day, no_check_t);
date(year, month, int, no_check_t);
date(year, int, day, no_check_t);
date(int, month, day, no_check_t);
// no date validity check parameters are in ymd orther.
date(int y, int m, int d, ymd_t);
Note the last one has the no_check before to avoid ambiguity as all
year, month and day are convertible to int.
I'm of course open to better names for no_check_t and ymd_t.
>>>> 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().
>
>
If I understand you make_date would behave as the / factory and is
useful for those that don't like the / factory syntax.
make_unvalidate_date() would use the no_check_t overloads.
Both would have the same set of of overload orders.
I would prefer to let pending these factory discussion. We could come
back once we agree on the date constructors.
Best,
Vicente