Le 03/05/13 13:39, Rob Stewart a écrit :
On May 2, 2013, at 10:19 PM, Anurag Kalia
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