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

4 May 2013

      Le 04/05/13 21:20, Rob Stewart a écrit :
...
On May 4, 2013, at 10:25 AM, "Vicente J. Botet Escriba"  wrote:
...
Le 04/05/13 14:50, Rob Stewart a écrit :
...
On May 4, 2013, at 3:29 AM, "Vicente J. Botet Escriba"  wrote:
...
Le 04/05/13 03:30, Rob Stewart a écrit :
...
On May 3, 2013, at 9:30 AM, "Vicente J. Botet Escriba"  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