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

Le 06/05/13 00:21, Howard Hinnant a écrit :

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? I would like for all. If we want to provide unchecked date construction it is normal to provide if it is a valid date later. But, ...

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.

I see. This means that the serial date can not provide the is_valid() function as we don't know, as Anaurag pointed out in the next post, if the stored date corresponds to maybe a valid date or not. is_valid can return a tribool in this case, and if the serial_date is validated at construction, the function return true, else return undefined. But this is not too useful if is_validated. BTW, N3344 suggest only ymd validation. Best, Vicente