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-03 09:14:11

Le 03/05/13 13:39, Rob Stewart a écrit :
> On May 2, 2013, at 10:19 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:
>
>> Vicente Botet wrote
>>
>>> Take in account that this is not just about naming parameters but about defining the design space. Note that
>>>
>>> day(32)
>>>
>>> will fail and throw an exception. If you don't want the check to be done you have the possibility to use a no_check tag
>>>
>>> day(7, no_check)
> I don't see the value of this. Yes, you can ensure the value is < 31, but you can't ensure that it doesn't exceed the range for a given month in the day type. Therefore, the validation should be done by the date constructor.
>
> IOW, I see two classes: year and day that are trivial value types holding an unsigned type with no validation. They exist solely to apply type information.
I could admit that the independent validation for the day could be 
redundant, but the year can be validated independently, so providing 
validated year don't need any further validation.
>
>>> In the same way the library provided some constant object for month we could add constant objects days for days, e.g. d_07 which is correct by
>>> definition. So the preceding examples could become
>>>
>>>      date d(d_7,dec,year(2013,no_check));
>>>      date d = d_7 / december / year(2013);
> At the very least, the names would need to be dayN or day_N. "d" seems insufficient. At that point, "day()" is only one or two characters longer.
>
> I don't like the day-of-month constants.
I have posted another thread for date suffixes.

Best,
Vicente