-
Notifications
You must be signed in to change notification settings - Fork 3
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
initial review of c <chrono> #2
base: master
Are you sure you want to change the base?
Conversation
@HowardHinnant I tried to provide an overview of the design of
|
This library is best understood as something that evolved over the past decade. It began with just chronological types and arithmetic and calendrical types/arithmetic have just recently been designed and are now in the draft C 20 working paper.
One can think of calendrical types such as The calendar serves to simply give memorable names to each value of To implement a "new" To implement a new calendar, the only real requirement is that it have a conversion to and from
The result is pretty ugly and will vary with implementation:
|
@HowardHinnant thanks for the quick answers! There was an SO question/answer stating that if a clock is not "realtime" it might not be advanced when a thread sleeps. Is that correct? If so, what is the associated thread of a clock and what does that mean for the |
From the C spec:
If the user writes a custom clock that does not advance when a thread sleeps, and then does a timed-sleep using that clock, that thread may never wake (it would depend on the details of the user-written clock). |
Thanks! |
Rendered.
TL;DR:
<chrono>
in Rust would look like:Lack of
const
trait methods could be worked around a bit, but the recursive trait declarations would be painful to workaround (one could add blanket impls). The real problem is implementing these traits. Even withconst generics
we would still need specialization, maybe with the lattice rule, and negative reasoning, to implement some of the traits. For example, we might want to add a generic implementation ofFrom
for all durations:which would conflict with the reflexive blanket impl in
std::covert
for the caseU=T
so we would need to at least add awhere U != T
clause there.