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-04 10:25:42

Le 04/05/13 14:50, Rob Stewart a écrit :
> On May 4, 2013, at 3:29 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>
>> 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.
> That isn't nearly as good as my suggestion. First, your ymd_t overload doesn't actually enforce that order of arguments.
This function is needed as there are people that are requesting a int 
based interface without named types. You can always use the other 
constructors.
>
> Second, your version doesn't permit other natural orders. It certainly forces YMD, except for the ymd_t overload, but it's less flexible.
>
> I agree with the addition of the no_check_t (or unchecked_t) parameter since using the dangerous unvalidated constructors should require extra effort and should be visible in the calling code.
>
>>>> 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().
> s/unvalidated_t/unchecked_t/ would be better.
I wonder if no_throw couldn't be adopted.
>
>> 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'm not entirely against the /-based factories, but they really don't offer an advantage over an ordinary make_date() function. The latter is also in keeping with make_shared(), make_unique(), and make_pair(). Furthermore, as I've noted in other posts, make_date() can be overloaded for unchecked, day of year, and weekday date construction use cases. One name to rule them all, so to speak.
Agreed. I suspect the /-based syntax was proposed as it is already used 
on the date domain. IMO, is a _nice_ to have feature.
>
>> I would prefer to let pending these factory discussion. We could come back once we agree on the date constructors.
> OK, but allow me to note that the date constructors and make_date() can have the same set of overloads, making them play together very nicely.
>
>
H.H. approach is a little bit different
* date constructors build unchecked dates
* date factories build checked dates

What do you think of this separation?

Best,
Vicenet