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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-04 08:28:44

On May 3, 2013, at 6:24 PM, Anurag Kalia <anurag.kalia_at_[hidden]> 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.

> 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);

> 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

(Sent from my portable computation engine)