Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Literal representing for days/weeks/months/years #790

Open
hewillk opened this issue Jul 24, 2023 · 1 comment
Open

Literal representing for days/weeks/months/years #790

hewillk opened this issue Jul 24, 2023 · 1 comment

Comments

@hewillk
Copy link

hewillk commented Jul 24, 2023

Hi Howard,

First of all, thank you for bringing such a wonderful library, and I am very happy that C++20 has finally adopted it.

I would like to know why the corresponding literal operator was not introduced when the duration aliases such as day/weeks/months/years were introduced because the duration aliases such as seconds that come with <chrono> have their corresponding literal operators.

I personally found it valuable to add a literals operator with the same name for them, which allows us to express the code more intuitively:

auto m = October; 
m += 8months;
auto y = 2004y + 300years;
auto d = 100d += 20days;
auto w = Sunday;
w += 2weeks;

So I wonder why they weren't introduced in the first place, is it because the names are too long? Or is there a specific reason?
Is it worth it or is it superfluous? I'd like to know your thoughts on this.

Thanks,
Hewill

@HowardHinnant
Copy link
Owner

Thanks for your kind words. I'm glad you found this library useful.

I think "superfluous" is probably the best description of my thought process. For me a literal is a more concise way of reading and writing a unit such as s or y. However when the whole type is spelled out in the literal name, the literal for becomes only two characters shorter:

m += months{8};

vs

m += 8months;

so it just didn't seem worth it to add the complication of two ways to write the same thing.

I struggled more with where to place the y and d literals: with the durations years and days or the calendrical specifiers year and day. I chose the calendrical specifiers from a hunch that they would end up appearing in code more often than the durations. I.e. with date literals such as:

auto constexpr epoch = 1601y/1/1;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants