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

On May 4, 2013, at 10:25 AM, "Vicente J. Botet Escriba" wrote:

Le 04/05/13 14:50, Rob Stewart a écrit :

...

On May 4, 2013, at 3:29 AM, "Vicente J. Botet Escriba" wrote:

...

Le 04/05/13 03:30, Rob Stewart a écrit :

...

On May 3, 2013, at 9:30 AM, "Vicente J. Botet Escriba" 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)