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

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:

...

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

...

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

Le 04/05/13 14:50, Rob Stewart a écrit : 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