[chrono/date] year/day/week literals
Hi, on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month. date dt(year(2013), may, day(3)); But having to use day(3) or year(2013) seems to wordy. I was wondering if we can not add some literals for day, year and week so that we can just write date dt(2013y, may, 3d); The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range. What do you think? Vicente
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
Oh I forget the drawbacks. As any other suffix it would need to add a using statement using boost::chrono::dates::literals; date dt(2013y, may, 3d); Are any standardized suffixes for day,week and year? Note that these are not the same as days, years, weeks. Best, Vicente
2013/5/3 Vicente J. Botet Escriba
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
Oh I forget the drawbacks. As any other suffix it would need to add a
using statement
using boost::chrono::dates::**literals;
date dt(2013y, may, 3d);
Are any standardized suffixes for day,week and year? Note that these are not the same as days, years, weeks.
Hmm, a user literal must start with '_', isn't it? My personal favor is that just one ctor in YMD order, so I won't need the literals, it's a programming style matter after all...
Le 03/05/13 16:04, TONGARI a écrit :
2013/5/3 Vicente J. Botet Escriba
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
Oh I forget the drawbacks. As any other suffix it would need to add a using statement
using boost::chrono::dates::**literals;
date dt(2013y, may, 3d);
Are any standardized suffixes for day,week and year? Note that these are not the same as days, years, weeks.
Hmm, a user literal must start with '_', isn't it?
date dt(2013_y, may, 3_d);
My personal favor is that just one ctor in YMD order, so I won't need the literals, it's a programming style matter after all...
You can the use date dt(2013, may, 3, no_check); Vicente
2013/5/3 Vicente J. Botet Escriba
Le 03/05/13 16:04, TONGARI a écrit :
2013/5/3 Vicente J. Botet Escriba
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
Oh I forget the drawbacks. As any other suffix it would need to add a
using statement
using boost::chrono::dates::****literals;
date dt(2013y, may, 3d);
Are any standardized suffixes for day,week and year? Note that these are not the same as days, years, weeks.
Hmm, a user literal must start with '_', isn't it?
date dt(2013_y, may, 3_d);
My personal favor is that just one ctor in YMD order, so I won't need the literals, it's a programming style matter after all...
You can the use
date dt(2013, may, 3, no_check);
IMHO, some static member functions would be simple and elegant (to me) date::ymd, date::mdy, date::dmy What Howard Hinnant had proposed may be a bonus to have date d = year(2013) / month(5) / day(3); But to be frankly with you, I'd like to save some typing. Best,
Le 03/05/13 18:12, TONGARI a écrit :
2013/5/3 Vicente J. Botet Escriba
Le 03/05/13 16:04, TONGARI a écrit :
2013/5/3 Vicente J. Botet Escriba
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
Oh I forget the drawbacks. As any other suffix it would need to add a
using statement
using boost::chrono::dates::****literals;
date dt(2013y, may, 3d);
Are any standardized suffixes for day,week and year? Note that these are not the same as days, years, weeks.
Hmm, a user literal must start with '_', isn't it? date dt(2013_y, may, 3_d);
My personal favor is that just one ctor in YMD order, so I won't need the literals, it's a programming style matter after all...
You can the use date dt(2013, may, 3, no_check);
IMHO, some static member functions would be simple and elegant (to me)
date::ymd, date::mdy, date::dmy After addition of some constructors you will be able create an unchecked date by typing only
date dt(2013, may, day(3), no_check); date dt(2013, may, 3_d, no_check); or date dt(year(2013), may, 3, no_check); date dt(2013_y, may, 3, no_check); or date dt(no_check, 2013, may, 3); date dt(no_check, 2013, 5, 3); Is this satisfactory for you?
What Howard Hinnant had proposed may be a bonus to have
date d = year(2013) / month(5) / day(3);
But to be frankly with you, I'd like to save some typing.
You have always the option date dt(no_check, 2013, may, 3); BTW, maybe we can change no_check by no_throw as this constructor will not throw even if the date is invalid. Of course it is UB if the date is invalid. date dt(no_throw, 2013, may, 3); Best, Vicente
On May 3, 2013, at 6:06 AM, "Vicente J. Botet Escriba"
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
Oh I forget the drawbacks. As any other suffix it would need to add a using statement
using boost::chrono::dates::literals;
That alone negates the wordiness argument. Few will type "day()" enough times, in a file, to offset that using directive.
date dt(2013y, may, 3d);
The number first order, and need for an underscore, is ugly to me. I'd prefer constants of the form dayN to this. ___ Rob (Sent from my portable computation engine)
2013/5/4 Rob Stewart
On May 3, 2013, at 6:06 AM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> wrote:
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week
so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will
have a compile error when the year, day or week is out of range. Oh I forget the drawbacks. As any other suffix it would need to add a using statement
using boost::chrono::dates::literals;
That alone negates the wordiness argument. Few will type "day()" enough times, in a file, to offset that using directive.
date dt(2013y, may, 3d);
The number first order, and need for an underscore, is ugly to me. I'd prefer constants of the form dayN to this.
Unfortunately '_' is required by the standard for a user-defined literal.
On May 4, 2013, at 11:16 AM, TONGARI
2013/5/4 Rob Stewart
On May 3, 2013, at 6:06 AM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> wrote:
Le 03/05/13 12:01, Vicente J. Botet Escriba a écrit :
Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week
so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will
have a compile error when the year, day or week is out of range. Oh I forget the drawbacks. As any other suffix it would need to add a using statement
using boost::chrono::dates::literals;
That alone negates the wordiness argument. Few will type "day()" enough times, in a file, to offset that using directive.
date dt(2013y, may, 3d);
The number first order, and need for an underscore, is ugly to me. I'd prefer constants of the form dayN to this.
Unfortunately '_' is required by the standard for a user-defined literal.
That was my point. I was arguing against the user defined literals. ___ Rob (Sent from my portable computation engine)
On 2013-05-03 12:01, Vicente J. Botet Escriba wrote:
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
What do you think?
Vicente
Do people actually hard code dates as often to make this necessary? We don't need to do something just because we can, we should do something that is useful and have a real life use case. Regards, Anders Dalvander
Le 04/05/13 20:38, Anders Dalvander a écrit :
On 2013-05-03 12:01, Vicente J. Botet Escriba wrote:
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
What do you think?
Vicente
Do people actually hard code dates as often to make this necessary?
We don't need to do something just because we can, we should do something that is useful and have a real life use case.
Do you think that I'm doing all that just because we can do it? Humm, if yes, you are right ;-) Best, Vicente
On May 4, 2013, at 2:38 PM, Anders Dalvander
On 2013-05-03 12:01, Vicente J. Botet Escriba wrote:
Hi,
on the GSoC discussion about Boost.Chrono/Date proposal we were discussing about date construction. Some of us think that we need to use named types for day, month, year and week so that the date constructors are not ambiguous. Everyone agree with the constant object for month.
date dt(year(2013), may, day(3));
But having to use day(3) or year(2013) seems to wordy.
I was wondering if we can not add some literals for day, year and week so that we can just write
date dt(2013y, may, 3d);
The advantage I see in addition to been less wordy, is that we will have a compile error when the year, day or week is out of range.
What do you think?
Vicente
Do people actually hard code dates as often to make this necessary?
We don't need to do something just because we can, we should do something that is useful and have a real life use case.
It doesn't seem like a stretch to me for an application, especially one about past events, to want to hard-code dates of historical significance. With today's technology, they can already hard-code them in a ymd format. It doesn't much of stretch to imagine that there could be a reason they might want to put them into rom as a serialized date. E.g. perhaps that would optimize the lookup of the date to find the associated historical significance. If constexpr'izing dates was exceptionally difficult, then perhaps the benefit wouldn't be worth the cost. However I've already implemented such constexpr computations using C++11, and yes it was somewhat of a pain. However it now appears that a significant subset of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3597.html has been accepted into the C++14 working draft, which will make constexpr'izing these computations trivial. The acceptance of this new language feature, imho, firmly adjusts the benefit/cost ratio up to an attractive level, especially since C++14 has also already constexpr'ed system_clock::time_point: the existing (but not yet fully exploited) serial representation of a modern date_time type. Howard
participants (5)
-
Anders Dalvander -
Howard Hinnant -
Rob Stewart -
TONGARI -
Vicente J. Botet Escriba