Howdy y'all; it is that time again, to talk about time.
We gathered a lot of great feedback and after sifting through it, weighing the pros and cons, and some prototyping, we have revised the proposal for Clock, Instant, and Duration.
This proposals' main aim remains the same: to provide a set of types to express scheduling work via temporal control.
Duration will remain nearly the same; but per issues that have been brought up we will no longer be lowering
Clock itself remains mostly the same except one small, but important, addition that was brought up to me in private during the review - and we tend to agree that this is a pretty important feature that was missing for power efficiency. That feature is tolerance. For repeated calls, the tolerance can allow for kernel level scheduling of wake-ups with a grace period of how accurate the sleep needs to be. Which in turn, when it is supported, the clock itself can offer a way to express from the caller to say; this is a very important sleep to be accurate upon, or it is a sleep that can have some level of drift to ensure coalesced wake-ups happen. This parameter will be optional. In the concrete clocks we are providing it will be nil by default (a dealers choice style parameter that the underlying implementation may decide on numerous factors for what type of reasonable tolerance can be applied).
Next up is
Instant. It was brought up that some
Instant types may need to express duration differently than just an integral time. Notable examples of this are things like clocks based on a GPU where the duration is frames, or a clock based on media where the duration is a rational. These are useful concepts that we should have the flexibility to handle while still retaining the ease of use for common integral values. After prototyping this, we feel that we have meet that balance while preserving the ergonomics that having just a shared concrete duration type serves.
Duration this type has not changed, except two points. It now adopts a
DurationProtocol which is the constraint for the associated type on
Instant. Additionally the static methods for calculating hours and minutes are removed (again).
The response was quite robust with regards to
WallClock - there were definitely some rough edges. Specifically the name
Date was not felt that it was appropriate to lower since it can cause confusion between a computational storage date and a human calendrical date. We heard this and we understand the objection. Ultimately we decided that it is best to leave
Date in the contextual frame of the home of calendrical APIs; Foundation. While looking at it from the frame of reference of Foundation, the name is reasonable when considering the material history of that type. It makes sense after getting over potential issues with regards to how it is a type devoid of timezone and calendar.
Date is intended to be used with
Calendar and we concur that moving, renaming, or altering the storage of
Date is not ideal. The primary driver for this issue is that of serialization. To alter the serialization method we would need to change considerably more, at considerably more risk, than what we think is reasonable for inflicting on Swift. That all being said; there is still a use case for a clock that has a type that can interface with calendrical systems. Scheduling a task to be woken up at 4PM tomorrow is perfectly reasonable and useful. We feel the discussion of
Date and and a clock that uses it is an integral part of this proposal; so included in the altered proposal is a section devoted to a new type,
UTCClock, in Foundation. Directly related to the feedback with regards to
Date; one major omission of the Foundation (and Darwin) APIs is a way of determining historical leap seconds - I definitely invite folks who have raised concerns about the accounting of leap seconds to weigh in.
Last but not least; we felt that the names of the concrete clocks previously proposed were quite opinionated with a bias to Darwin nomenclature. The names on Darwin for C APIs (as well as other BSD like platforms) take the meaning of "monotonic" as continuously increasing even during sleep of the machine, and "uptime" to be suspending increases while the machine is asleep. Whereas the names on Linux based operating systems are exactly the opposite. We feel that names describing the behavior are much more appropriate for a language that is being developed to be cross platform than picking names from precedent of other APIs. We have renamed
MonotonicClock to be
ContinuousClock and the
UptimeClock to be
SuspendingClock. To this end we have included some of the alternatives we have considered during this renaming process to aide the discussion by giving some clarity on why we picked what we did.
Since the proposal exceeds the length of posts (perhaps I am a bit too wordy) the most recent revision can be found here.