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-04 16:15:35

Le 04/05/13 21:20, Rob Stewart a écrit :
> On May 4, 2013, at 10:25 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>
>> Le 04/05/13 14:50, Rob Stewart a écrit :
>>> On May 4, 2013, at 3:29 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>>>
>>>> Le 04/05/13 03:30, Rob Stewart a écrit :
>>>>> On May 3, 2013, at 9:30 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>>>>>>   
>>>>   // no date validity check parameters are in ymd orther.
>>>>   date(int y, int m, int d, ymd_t);
>>>>
>>>> Note the last one has the no_check before to avoid ambiguity as all year, month and day are convertible to int.
>>>>
>>>> I'm of course open to better names for no_check_t and ymd_t.
>>> That isn't nearly as good as my suggestion. First, your ymd_t overload doesn't actually enforce that order of arguments.
>> This function is needed as there are people that are requesting a int based interface without named types. You can always use the other constructors.
> People often want things that aren't good for them, so that's not a great argument. Still, my opinion isn't the only one that matters.
>
>>>>> make_unvalidate_date().
>>> s/unvalidated_t/unchecked_t/ would be better.
>> I wonder if no_throw couldn't be adopted.
> That could work.
>
>>>> If I understand you make_date would behave as the / factory and is useful for those that don't like the / factory syntax.
>>>> make_unvalidate_date() would use the no_check_t overloads.
>>>> Both would have the same set of of overload orders.
>>> I'm not entirely against the /-based factories, but they really don't offer an advantage over an ordinary make_date() function. The latter is also in keeping with make_shared(), make_unique(), and make_pair(). Furthermore, as I've noted in other posts, make_date() can be overloaded for unchecked, day of year, and weekday date construction use cases. One name to rule them all, so to speak.
>> Agreed. I suspect the /-based syntax was proposed as it is already used on the date domain. IMO, is a _nice_ to have feature.
> I realize that / is common in writing dates, but a great many natural notations map poorly to C++. Howard's notation seems too cute to me, but we each have different sensibilities.
>
>>>> I would prefer to let pending these factory discussion. We could come back once we agree on the date constructors.
>>> OK, but allow me to note that the date constructors and make_date() can have the same set of overloads, making them play together very nicely.
>>>
>> H.H. approach is a little bit different
>> * date constructors build unchecked dates
>> * date factories build checked dates
>>
>> What do you think of this separation?
> There's some value in it. I replied separately that the choice of syntax should not dictate whether checking occurs.
>
> However, it has just occurred to me that the make_date() I've been discussing is just another spelling of the constructor name unless there are different return types based upon the argument list.
I expect there will be several classes.
> If there are different types, then make_date() provides a consistent interface. Otherwise, I'd be most interested in a full featured date class. That leaves the / factories as pure syntactic sugar.
>
What do you expect from a "full featured date class"? Would this 
correspond what I have called a Date concept?

I have just extracted from my current interface some of the functions 
that we could have in a full featured date class.

class date;

date today();

class date {
public:
   // construct/copy/destruct
   date(); // |year(0)/jan/1|
   date(year, month, day);
   date(year, month, day, no_check_t);
   // and all the usual combinations
   bool set_if_valid_date(year, month, day);
   day day() const; // or explict operator day(); the same for the other 
accessors.
   month month() const;
   year year() const;

   date(year, week, weekday);
   date(year, week, weekday, no_check_t);
   bool set_if_valid_date(year, week, weekday);
   week week() const;
   weekday weekday() const;

   date(year, day_of_year);
   date(year, day_of_year, no_check_t);
   bool set_if_valid_date(year, day_of_year);
   day_of_year day_of_year() const;

   explicit date(days);
   date(days, no_check_t);
   bool set_if_valid_date(days);
   days days_since_epoch(); // or time_since_epoch() or just days()

   explicit date(system_clock::time_point);
   operator system_clock::time_point() const;

   bool is_valid() const;
   bool is_leap_year() const;

   date & operator+=(days);
   date & operator++();
   date operator++(int);
   date & operator-=(days);
   date & operator--();
   date operator--(int);
   date & operator+=(months);
   date & operator-=(months);
   date & operator+=(years);
   date & operator-=(years);

   // friend functions
   friend date operator+(date, days);
   friend date operator+(days, date);
   friend date operator-(date, days);
   friend days operator-(date, date);
   friend date operator+(date, months);
   friend date operator+(months, date);
   friend date operator-(date, months);
   friend date operator+(date, years);
   friend date operator+(years, date);
   friend date operator-(date, years);
   friend bool operator==(const date &, const date &);
   friend bool operator<(const date &, const date &);
   friend bool operator!=(const date &, const date &);
   friend bool operator>(const date &, const date &);
   friend bool operator<=(const date &, const date &);
   friend bool operator>=(const date &, const date &);

};

Best,
Vicente