Proposal to add epoch properties to SuspendingClock and ContinuousClock #2722
Conversation
| * Status: **Awaiting implementation** | ||
| * Implementation: | ||
|
|
||
| * Previous Proposal: *if applicable* [SE-0329](0329-clock-instant-duration.md) |
There was a problem hiding this comment.
This isn't really a previous proposal
|
|
||
| It was considered to add a constructor or static member to the `SuspendingClock.Instant` and `ContinousClock.Instant` however the home on the clock itself provides a more discoverable and nameable location. | ||
|
|
||
| It is suggested that this be used as an informal protocol for other clocks. It was considered as an additional protocol but that was ultimately rejected because no generic function made much sense that would not be better served with generic specialization or explicit clock parameter types. |
There was a problem hiding this comment.
Probably worth discussing that we could add an EpochalClock protocol in the future if we discovered that it actually was useful for generics.
|
|
||
| ## Alternatives considered | ||
|
|
||
| It was considered to add a constructor or static member to the `SuspendingClock.Instant` and `ContinousClock.Instant` however the home on the clock itself provides a more discoverable and nameable location. |
There was a problem hiding this comment.
Re: statics, would anyone ever have a clock type where two different instances had different epochs? If so, that's probably a strong argument against the design; if not, that makes a static property seem more reasonable.
There was a problem hiding this comment.
One argument might be that this could be like static bitWidth and instance bitWidth on integers: if a particular type of clock (or protocol) always has the same epoch for every instance, then there could be additionally a static property, but an instance property being always available would be useful if the primary use case contemplated is working out elapsed time. Having to reach for a static property forces the user to take a beat to reflect that the epoch happens to be the same for all instances of the same type—which might be salient knowledge for other work but is neither here nor there for clock.now - clock.epoch.
| @@ -0,0 +1,58 @@ | |||
| # Clock Epochs | |||
|
|
|||
| * Proposal: [SE-NNNN](NNNN-ClockEpochs.md) | |||
There was a problem hiding this comment.
Existing proposals use kebab-case.md:
| * Proposal: [SE-NNNN](NNNN-ClockEpochs.md) | |
| * Proposal: [SE-NNNN](NNNN-clock-epochs.md) |
| ## Detailed design | ||
|
|
||
| ```swift | ||
| extension ContinousClock { |
There was a problem hiding this comment.
(1 of 3)
| extension ContinousClock { | |
| extension ContinuousClock { |
| These can be used to gather information like for example the uptime of a system, or the active time of a system; | ||
|
|
||
| ```swift | ||
| let clock = ContinousClock() |
There was a problem hiding this comment.
(2 of 3)
| let clock = ContinousClock() | |
| let clock = ContinuousClock() |
|
|
||
| ## Alternatives considered | ||
|
|
||
| It was considered to add a constructor or static member to the `SuspendingClock.Instant` and `ContinousClock.Instant` however the home on the clock itself provides a more discoverable and nameable location. |
There was a problem hiding this comment.
(3 of 3)
| It was considered to add a constructor or static member to the `SuspendingClock.Instant` and `ContinousClock.Instant` however the home on the clock itself provides a more discoverable and nameable location. | |
| It was considered to add a constructor or static member to the `SuspendingClock.Instant` and `ContinuousClock.Instant` however the home on the clock itself provides a more discoverable and nameable location. |
This is a proposal to match the SuspendingClock and ContinuousClock epochs µPitch.