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-04 15:20:12

On May 4, 2013, at 10:25 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

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

People often want things that aren't good for them, so that's not a great argument. Still, my opinion isn't the only one that matters.

>>>> make_unvalidate_date().
>> s/unvalidated_t/unchecked_t/ would be better.
> I wonder if no_throw couldn't be adopted.

That could work.

>>> 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 realize that / is common in writing dates, but a great many natural notations map poorly to C++. Howard's notation seems too cute to me, but we each have different sensibilities.

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

There's some value in it. I replied separately that the choice of syntax should not dictate whether checking occurs.

However, it has just occurred to me that the make_date() I've been discussing is just another spelling of the constructor name unless there are different return types based upon the argument list.

If there are different types, then make_date() provides a consistent interface. Otherwise, I'd be most interested in a full featured date class. That leaves the / factories as pure syntactic sugar.

___
Rob

(Sent from my portable computation engine)