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

On May 5, 2013, at 4:11 PM, Vicente J. Botet Escriba wrote:

Le 05/05/13 13:28, Rob Stewart a écrit :

...

On May 4, 2013, at 5:16 PM, Anurag Kalia wrote:

...

"natural" factory function -

(the last argument also has an int for succinctness)

year / month / day; day / month / year; month / day / year;

This notation extends as -

weekday[n] / month / year;

and so on. Considering Vicente's concept plan, a user-defined date type can be extended readily via make_date(), but not via this notation. I'd consider that another argument against this unless the design provided specific customization points to enable new date types. Rob, please could you clarify the preceding paragraph?

...

1) I have dropped no_check option. It is verbose and I never liked that. The constructor has a 'raw' feeling to it that lends itself well to an unchecked constructor. We have the other two categories of functions that check the validity. Why not simply offer, say, date and raw_date? Pick any two names, but one is checked and the other not. Derivation or composition can simplify the implementation if the checked version in terms of the unchecked. I like when the C++ type system is used to mean different invariants.

raw_date d1 ; date d2 = d1; // throws if d1 is not valid

This moves the play from looking a better name for no_check to one for raw_date.

Independently I was exploring a is_validated() and validate() functions. See the specific post. With your approach these two functions have no sense of course as it is the type system that plays the role: raw_date::is_validated() ==false date::is_validated() == true and the validate function is the conversion from raw_date to date.

Is this being considered for field types, serial types, or both? The reason I ask is that all serial values are valid dates, at least those in range, and we can make the range as big as we want. It is only the field types that are problematic when day, month, or week is out of range. Howard