Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager, either via email or PM on these forums. When emailing me directly, please put "[SE-0374]" at the start of the subject line.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
In the "alternatives considered" section, the proposal states:
The only potential problem would be if someone has already run into this shortcoming and decided to define their own sleep(for:) method on clocks.
I would like to clarify that this would not really be a problem; their code would continue calling their implementation until they decided to remove it. It is vaguely plausible that their implementation would not be semantically compatible with the stdlib implementation, but this is quite unlikely given the nature of the operation, and probably would indicate a bug in their implementation that should be fixed anyway.
Enthusiastic support for this proposal, the use cases motivating the proposal are relevant to my team and the features we implement, preview and test.
During the pitch, this comment was made:
Perhaps what follows is reading a bit too much into the above comment. While I can't imagine how else it might work, could there be a way of avoiding the existential (that is, use a concrete type only) whose behaviour can be controlled environmentally, much like how a Task can inherit priority, could it inherit a clock or the clock inherit a way to control the passage of time?
Availability details are at the discretion of the platform vending the stable ABI, rather than Evolution. Technically there is no obstacle to doing so in this case, and it is in-line with API that we have done this for in the past, so I expect that we would do it here as well.
I think that is a very reasonable request that we should do; basically pull it back to as if it were introduced in the same release as Clock itself.
Per the tolerance part; that is a good catch - it is of course still available in the Instant form of that API but it would make the on-ramp of the progressive disclosure even smoother (with little to no impact on maintenance). sleep(for:) progresses to sleep(for:tolerance:) to sleep(until:clock:) to sleep(until:tolerance:clock:). So yea that seems like a very minor and reasonable addendum.
The question as to whether a proposed feature will be back-deployed is at the discretion of the platform vendor, but the question whether a feature can be back-deployed is a relevant question for the purposes of the Evolution process, IIUC, that falls under the “impact on ABI” part of the proposal.
Many time-related APIs in Foundation use this pattern you defined as "instant-based" as their primary mechanism and I always thought it was weird that they didn't include conveniences like the proposed one given that this is what most people tend to use them for.
Existentials aren't so bad - especially now that we can use the language's actual existentials for PATs. I've found that the compiler is quite good at devirtualising them, so they can perform identically to generics in many situations.
For something like this where you're going to be suspending for some appreciable amount of time anyway, I think the overhead of using an existential is going to be negligible. And if you do find it to be significant, you can still opt for a restricted set of concrete types by defining an enum. In any case, this function would still be a convenient addition.
Please don’t get me wrong, I understand and completely agree with this, but I tend to think of the method as more of a necessary addition given the obvious pain points it solves. My point in bringing it up was to stimulate some imaginative discussion where developers could control the passage of time or not with the same concrete type.
