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 14:29:15

On May 4, 2013, at 12:10 PM, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:

> On May 4, 2013, at 12:01 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:
> 
>>> I think I see the disconnect.  Simplifying as much as possible (hopefully
>>> not too much), you prefer:
>>> 
>>>  days_date(year::rep, month::rep, day::rep, no_check_t);
>>> 
>>> whereas I prefer for the same functionality:
>>> 
>>>  days_date(year, month, day);
>>> 
>>> or for the sake of removing part of the debate:
>>> 
>>>  days_date(year, month, day, no_check_t);
>>> 
>>> Your design doesn't require that year, month and day objects be "validation free", but mine does.
>> 
>> Howard, I am curious why are we not trying to make the default date type
>> beginner-proof? Is it because we already have the "slash" form that validates the date?
> 
> I think Vicente put it best:
> 
> On May 4, 2013, at 10:25 AM, Vicente J. Botet Escriba <vicente.botet_at_[hidden]> wrote:
> 
>> H.H. approach is a little bit different
>> * date constructors build unchecked dates
>> * date factories build checked dates
> 
> I found this separation of behaviors to be something easily learned, remembered, and does not require the no_check_t syntax.

Both the constructors and make_date() can be overloaded with and without unchecked_t or no_check_t. That means the choice of syntax can be left to the user and context, rather than based upon checking or not.

Nevertheless, I recognize there's value in the distinction you're making.

___
Rob

(Sent from my portable computation engine)