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-05 19:30:43

On May 5, 2013, at 4:11 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> Le 05/05/13 13:28, Rob Stewart a écrit :
>> On May 4, 2013, at 5:16 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:
>> 
>>> "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.
>> Considering Vicente's concept plan, a user-defined date type can be extended readily via make_date(), but not via this notation. I'd consider that another argument against this unless the design provided specific customization points to enable new date types.
> Rob, please could you clarify the preceding paragraph?

Try this:

I think your idea of date concepts has merit. Given such concepts, a user-defined date type could be used by various algorithms if they satisfy an appropriate concept.

With that support for extensibility, thought should be given to how such types can fit into the factory interfaces, too. make_date() can be extended trivially in the user's namespace. The same is not true of the /-based interface.

___
Rob

(Sent from my portable computation engine)