Big +1 from me. This is an extremely useful API, and yet quite difficult to get right whilst still allowing non sendable and non escaping closures.
I have tried adopting this in my project and found it works well, the error types are very nicely done as i can easily switch over the cause and know exactly what went wrong.
Could you elaborate on why we can't do both?
In your PR you've stated:
This approach was rejected because deadline-based APIs provide better
composability and semantics.
But why does the composition have to be up to the package client? Most developers aren't going to reach of withDeadline. While withDeadline is definitely way more flexible, what we NEED is withTimeout. Other languages also include withTimeout that has a similar API to the one originally proposed.
The “other languages” argument goes both ways. Go gets this right and it is modeled as deadlines there. A simple timeout is just the and as a deadline of “now + time” but deadlines are more expressive and actually compose.
You’re right about that. I don’t disagree with the deadlines approach as a base. It's much more powerful. I just think there's an argument for going with the more discoverable name.
withTimeout(deadline: .now.advanced(by: .seconds(5)))
Mixing up deadline and timeout like this is confusing and poor API design, in my opinion.
Maybe folks missed that this pitch has already gone to review. I recommend moving comments over to the proposal thread to ensure they aren’t overlooked before the review concludes on Friday.
Thanks Kyle, I didn’t notice this reply was in the wrong thread. I’ll close this pitch thread to avoid prolonging discussion in the wrong spot