Make implicit units on TimeInterval explicit

I‘m not adding one, it‘s already there!

It does add up to one second, why wouldn‘t it? It does as 0.7 + 0.3 would, which is the alternative right now for TimeIntervals.

1 Like

@QuinceyMorris means that a simple Double alias doesn't try to hide the subtleties of floating numbers computations. For example, 100/1000.0 + 200/1000.0 == 300/1000.0 is false. But nobody with a little experience of doubles expects 0.1 + 0.2 to be equal to 0.3. On the other side, .milliseconds(100) + .milliseconds(200) looks like it performs exact computations on integers, when it is not.


I see what you mean, and you are right, of course. It does look like it’s exact calculation. But since the type is TimeInterval which is Double, I wonder if this really is such a problem …

It's not guaranteed to be exact - that's a general problem of floats.
The same problem happens when someone publishes a measurement with lots of decimals, although the gauge has high scattering (so basically random data that only gives a false feel of precision)
I wouldn't consider that to be the show stopper here, though.

I guess that there is no problem as long as the API does not try to hide that TimeInterval is a Double. Or, to write my point of view more clearly: I’m not surprised that your suggestion triggers reactions :-)

Actually, in a perfect world I would rather expect there to be a perfect type representing intervals in Swift which we can use everywhere and which support everything we need, including days, months and years in all calendar systems we like.

But, in our everyday work we are using UIKit which has many APIs which expect a TimeInterval. If I didn’t see the DispatchTimeInterval type from Apple, I actually wouldn’t have even considered to pitch this change to Swift. But we have two time interval types in Foundation, one of it has explicit units, the other doesn’t. And the one that doesn’t is part of the more often used APIs in UIKit. I feel like we should at least harmonize these types.

Maybe we don’t need it in 15 years when Apple rewrites its APIs, but we need it in the meantime and millions of projects include implicit units. I feel like that’s worth this rather small change.

As TimeInterval is in Foundation, you’d need to go through the Radar process to change it. I’m guessing it is too late now for this to ship in iOS 12, so optimistically you’d need to wait 1.5 years for it to appear in iOS. But then you’d probably still need your app to work on previous iOS versions, so I’m estimating around 4-5 years till you will be able to use this in your code. And that’s assuming Apple agrees to add this feature.

So at this point you might as well wait for a new API…

I really don’t get your point: Why can’t we add an extension to TimeInterval into the open source Swift project? TimeInterval is being used in many places and it was even defined ad-hoc in a test here. Is it really not part of what we can change via Swift Evolution?

Properly speaking, the Swift Evolution Process is defined as below (emphasis mine):

The Swift evolution process covers all changes to the Swift language and the public interface of the Swift standard library, including new language features and APIs (no matter how small), changes to existing language features or APIs, removal of existing features, and so on.

Contributions to Foundation are described here (where I learn, among other things, that Foundation evolution happens on this very Swift Evolution Forum). Generally see for informations about Swift and its various sub-projects.

Note that this is corelibs-foundation, which is different from Foundation and CoreFoundation.

All right.

From, I did follow “Core Libraries”, from which I found “Foundation”, which links to, which contains the CONTRIBUTING guide linked above, which tells that the evolution if this library happens in this forum.

I expect TimeInterval to be defined here… Yes it is.

So sorry for the naming confusion: the lib called “corelibs-foundation” is unfortunately linked as “Foundation” from

It would be interesting, @nick.keets, that you remind us with the relationships between the three libraries… The Objective-C Foundation used to be built on top of the C CoreFoundation, but now… Is corelibs-foundation just for Linux, when Apple platforms keep on using Apple-owned Foundation/CoreFoundation? How is evolution supposed to happen, then?

I already posted a link few posts back, but let me quote it for greater visibilty:

My understanding as a complete outsider, is that this is a classic application of Conway’s law. Unless some kind of intervention happens, then Swift, Foundation and Dispatch are just going to keep moving in parallel ways.

Granted, Nick. Actually, the API Changes paragraph of corelibs-foundation is short, to-the-point, and a must-read for whoever wants to change Foundation.

Sure, here is another quote about a different feature request for Foundation:

In any case I believe that my comment still stands about changes to Foundation requiring in the order of 5 years till they become realistically available.

At least @Jeehut knows which door he has opened :-) Thanks @nick.keets for your patience!

I think this is closely related to the thread about “Non-Standard Library”. If we had a CocoaPods-like hub for libraries, this could trivially be added to it for people who think it’s worth it. Then we could discuss if the feature is worth including with Swift distributions, but that discussion could be based on real-world usage data and experience. And not including it would still mean that anyone could trivially install the feature as an external dependency. Which is still easily possible today, just the discoverability isn’t stellar.


Independent of the practical problems of getting a change into Foundation, the main problem I have with this pitch is that – because TimeInterval is just a typealias – the proposed changes would “pollute” the namespace of Double.

So not only could you write:


But these would also be legal:

200.0.milliseconds // type is Double, not TimeInterval

I don’t think this is desirable.

I agree with @salutis’s post that a better long-term solution would be to drop TimeInterval in favor of Measurement<UnitDuration> (and similarly for angles etc.).