Notices by namark (namark@qoto.org)

@codewiz the main point is that it's a nuanced issue out of scope for chrono. Any halfway solution would achieve very little and lower the quality of the library. The arithmetic bound checking is universally applicable, so it would be kind of silly to have something for durations that you couldn't use for other types. Also imposing any sort of compile-time, run-time or maintenance overhead any such checks would bring is nonsensical in a world where everyone in every other application of arithmetic is perfectly happy to just use a type that is assumed to be "large enough" to represent any value. Most just want to use a 64 bit int, and forget it can overflow, even at nanosecond precision, and some would vehemently argue that even on systems that don't have wide enough words, it should just be emulated in software.

@codewiz another thing you could do is define and use your own bound checked literals of different sizes. Here is an example for just plain integers
https://git.sr.ht/~namark/libsimple_support/tree/master/item/source/simple/support/int_literals.hpp

If you stick with just one duration type throughout the codebase that would be all you need, otherwise if you want to mix and match duration of different granularity and size, your custom literals can return a wrapper type that would only be implicitly convertible to durations that they can fit in.

@codewiz keeping in mind that it's still a half measure, which won't save your from many potential pitfalls. For anything non trivial you'd still need to do a lot of mental (or pen and paper) calculations to make sure there is no overflow, so literals would be the least of your concerns on that front.

@codewiz you seemed to have a problem with the concept so that was an explanation and a proof of concept implementation. Pleasantly surprised it worked at all! If you care about it you should participate, cause as far as I know that is the most developed of any such concepts:
https://github.com/boostorg/safe_numerics

common_type trait sounds like a misnomer, but I imagine chrono didn't have anything better to use. safe_numeric may provide alternatives on that front, though it will likely never be standardized in it's current form. It's much more likely for a more generic numeric library to get in, that would also handle arbitrary precision and provide the safe_numerics functionality as its subset, and probably not called "safe" cause that's not a very good name either.

@codewiz exception, abort or compiler error?

yes

https://yewtu.be/watch?v=93Cjg42bGEw

https://www.boost.org/doc/libs/develop/libs/safe_numerics/doc/html/index.html