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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-05 16:11:47

Le 05/05/13 13:28, Rob Stewart a écrit :
> On May 4, 2013, at 5:16 PM, Anurag Kalia <anurag.kalia_at_[hidden]> 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.

I like it.

Best,
Vicente

Best,
Vicente