Good suggestion. Now to consolidate my view up till now, I have following types of date construction in mind:
1) Unchecked:
simple ymd constructor -
date(year, month, day); date(day, month, year); date(month, day, year);
2) Checked:
"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; Does the preceding build a contextual or non-contextual date?
To be noted: 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. I have not yet a clear position on this concern. It is clear to me that /() factories must be checked as we can not state
Le 04/05/13 23:16, Anurag Kalia a écrit : the opposite.
2) I include the named factory functions because there seems no other way to make a date with so myriad options. The consistent naming indicates that the same object is being produced; which is exactly what needs to be said.
Do you mean that make_date would provide more services than the expression template using operator/()?
3) The "natural" construction (really, we need some name for them) is actually natural. I particularly like the dmy notation in this case, with last argument as int:
day(25) / dec / 2013;
As for the constants, the jan, feb, ..., dec as well as sun, ..., sat are there. Moreover, there are also _1st, _2nd, ... , _31st and last.
There is nothing for these : day(1) and week(4). It is because the are not widespread and this notation is much more clear than any enumeration.
Sorry I missed your position. Could you clarify what are you proposing? Best, Vicente