Hi @Philippe_Hausler!
This is absolutely fantastic. I've let some time go by after reading the document once, and on second reading it's even better! I agree with @davedelong that the changes overall strengthen the final design significantly.
A few questions and points of feedback:
I agree with others that the Interval
versus Duration
terminology is weird. Additionally—and I don't think this has been mentioned—recall that in earlier versions of Swift Interval
was a standard library type that got coalesced into Range
: it would be nice not to resurrect that name for something that's totally different.
If another word would be useful for the associatedtype
, might I suggest TimeSpan
, which is obviously time-related unlike Interval
.
However, I think it's quite fine not to use two different words: indeed, the standard library ExpressibleBy*
types define associated types that have the same name as global type aliases (e.g., StringLiteralType
is an associated type of ExpressibleByStringLiteral
and also a global type alias).
I agree with @scanon re the weirdness of the DurationProtocol
: if it's not needed, that would be fantastic.
I also have some questions regarding the operators it (and the concrete type Duration
) exposes, which center around this: is there an implementation reason that multiplication by arbitrary integer types is a requirement, while division of two conforming types produces a Double
result? It would seem logical that multiplication would be by Double
values also (which as you know can represent all consecutive integers exactly up to 2 ** 53
, and which I notice the concrete Duration
type supports)... Do the integer overloads have to do with what you were referring to in your reply about "ensur[ing] fast paths for calculating certain durations"?
I think I understand the usefulness of the newly pitched minimumResolution
API. Two minor points about the name:
- First, I think there are two subtly different interpretations a user could have: either (1) "great! this clock guarantees that it's at least that accurate"; or (2) "oh! I shouldn't expect two points in time less than that to be distinguishable." Maybe I'm confusing myself and these two are essentially the same statement, but I think this is boiling down to accuracy versus precision, and I'm not exactly sure which one we're trying to represent here and whether there is a common term-of-art in computer timekeeping for it other than "resolution." The proposal also uses the term "granularity" to describe the API—I wonder if there's way to clarify this not only through the explanatory text but in the name of the property itself.
- The standard library, usually eschewing abbreviations, has adopted
min
and max
as the spelling of "minimum" and "maximum" throughout, with the sole exception of the floating-point IEEE "minimum" and "maximum" operations that are deliberately named distinctly from Swift.min
since they handle NaN values differently. Even if we stick to the term "resolution," the API would be more consistently named minResolution
.
I agree with @davedelong that it's (only a bit) unfortunate that we'd not have a standard library wall clock. I think the revised approach of not putting it in the standard library makes a lot of sense when interfacing with an unchanged Foundation.Date
type is essential, while still allowing for use with these modern non-calendrical APIs via conformance to ClockProtocol
. Overall, I like this approach very much so long as we don't close the door to something like the approach which swift-system
takes with FilePath
with a potentially separate system clock project (obviously without necessarily committing to such an approach)—based on what I'm seeing in the proposal, there shouldn't be any barriers to third-party libraries tackling this space, correct?