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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-03 13:46:10

Le 03/05/13 18:06, Vicente J. Botet Escriba a écrit :
> Le 03/05/13 16:58, Howard Hinnant a écrit :
>> I have been reading with interest this thread, but have been sitting 
>> on my hands until now.  After all this is a gsoc project for Anurag, 
>> not for me or anyone else.
>>
>> But as long as everyone seems free to throw in their design 
>> preferences, I will add mine, several of which I've already seen 
>> repeated here, but some not.
>>
>> Unchecked interface:
>> --------------------
>>
>>     date(year y, month m, day d);
>>
>> This is the only order, there is no checking, the year, month and 
>> date objects do no validation themselves.  They exist only to 
>> disambiguate the order of this low level constructor.  This single 
>> order is chosen above any other because of the ISO standards.  The 
>> use of the year, month and day objects add some type safety with no 
>> run time overhead, and so are acceptable. Each of these objects will 
>> *explicitly* convert from int:
>>
>>     date(year(2013), month(5), day(3));  // ok
>>
>>     date(2013, 5, 3);  // compile time error
>>
>> I dislike the use of no_check_t at this level because I see it as 
>> unnecessarily verbose and ugly, and I'll have to look up how to spell 
>> it every time I use it (see the checked interface for why).
> Hi Howard,
>
> my guess with no_check was to make it more difficult to build an 
> unvalidated date than a validated one. Wouldn't an beginner user start 
> using the unchecked constructors before the factory functions?
>
>> Checked interface:
>> ------------------
>>
>> I like the use of factory functions here.  I also like an 
>> easy-to-remember, convenience, forgiving, type-safety.  My 
>> still-preferred spelling for the factory functions (yes, more than 1) 
>> is:
>>
>>     date d = year(2013) / month(5) / day(3);
>>     date d = year(2013) / month(5) / 3;
>>     date d = month(5) / day(3) / year(2013);
>>     date d = month(5) / day(3) / 2013;
>>     date d = day(3) / month(5) / year(2013);
>>     date d = day(3) / month(5) / 2013;
>>
>> These 3 orders are chosen among the possible 6 because these are the 
>> 3 that people actually use:
>>
>>     http://en.wikipedia.org/wiki/Date_format_by_country
>>
>> The first two units have to explicit.  The last unit can be 
>> implicit.  Other rules are possible, but this one is a nice 
>> compromise between convenience and simplicity.  It is an easy rule to 
>> remember, and the rule is easily checked by the compiler at compile 
>> time.
>>
>> I like this spelling of the checked factory function over:
>>
>> make_unchecked_date(2013, may, 3);
>> or
>>
>> make_valid_date(2013, may, 3);
>>
>> because I know I will remember how to spell the former 3 years from 
>> now, but I will have to look the latter up in a reference, unless I'm 
>> dealing with dates often enough that I memorize it.
> Again I proposed these functions for the no_check date construction. 
> Nothing to be with the checked one. Anyway I don't like them more that 
> the no_check constructor.
> I like the factories for the check interface.
>> In both interfaces, the year, month and day objects do no validity 
>> checking.  The validity checks in the checked interface happen only 
>> at the time the full date is constructed.
> I would expect that month and year could be check its validity so no 
> check is needed when using constant objects. BTW, Howard, could you 
> comment on my post about date literals for day and year?
>
Howard, I believe I start to understand why you don't want 
day/month/year to validate its input.
I suspect that the rationale is quite simple, you are relaying on 
undefined behavior when the value of these parameters is out of range, 
isn't it?

Best,
Vicente