Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-03 07:39:18
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
>> 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.
>> 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.
>> If no check is desired the following could construct a date efficiently.
>> date d(d_7,dec,2013,no_check);
>> Note that the operator/() factory don't allows you to avoid the validity check.
We're agreed here, aside from the spelling. That is, I get the same from this:
date(day(7), dec, 2013, no_check);
> I realize it. But there is no need for bounds to be so intricately defined.
> A person either wants to define a date, or not. So, I suggest to leave out the checks from day, month and year and let them be checked only when constructing the actual date.
Ah, right. You said the same thing as I.
> We are not expecting, after all, that these day or month classes would be used independently after all. In fact, one of the strengths of functional approach [ day(2013, 05, 03) ] is that it lets us drop the redundant usage of day, month and year in the syntax.
That form isn't clear.
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk