Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-05-04 17:16:31

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-tp4646142p4646670.html
Sent from the Boost - Dev mailing list archive at Nabble.com.