Rob Stewart-6 wrote
On May 3, 2013, at 6:24 PM, Anurag Kalia <
anurag.kalia@
> wrote:
Why are we not using following constructor?
date(int year, int month, int day);
The compiler cannot prevent a user from mistakenly writing date(5, 4, 2013) when the intent was date(2013, 5, 4).
To clarify my position, benefits are not apparent to me. Since the order is strictly-defined, the writer of code has to remember the ordering in both cases. OTOH an year is typically in thousands:
date(2013, 5, 3);
It should ring a bell towards the ymd notation. The fact that constructor is named date already gives away its purpose.
You're presuming familiarity and thoughtful use. Programmers are lazy and frequently hurried, so it's better to prevent errors by forcing date(may, 5, year(2013)).
Your argument WRT the year being larger than any valid day or month is interesting, but applies only if you support years greater than, say, 100.
The vast majority of dates are supposed to be greater than year 100. Actually, vast majority are supposed to be greater than 1900. So that is not a problem. But any bug should be avoided. So, I am not really against the initial constructor. It is just that it doesn't seem to hit the right spot between natural and explicit.
I am still waving for functions like:
make_ordinal_date(2013, 45); make_week_date(2013, w7, 5);
Is 5, in the latter, the day of the week? If so, I recommend a constant (or enumeration):
make_week_date(2013, w7, fri);
That looks good. I like that syntax; i hope nobody else minds it.
Because mixing them with other constructors would be confusing. Keeping the notation to make them seprately, but part of same date class at the end, is something like their relation with actual gregorian calendar.
At which point I wonder, why can't we be symmetrical and allow a function like:
make_date(2013, 2, 27);
You could have these, instead, for more consistency:
make_date(2013, 45); make_date(2013, w7, fri);
___ Rob
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; and so on. 3) Again, checked: But named factory functions, follows ISO conventions - make_date(year, month, day); make_date(year, week, weekday); make_date(year, day_of_year); 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. 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. 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. Thoughts? There should be many. Regards, Anurag. -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-... Sent from the Boost - Dev mailing list archive at Nabble.com.