Make NIOLoopBoundBox off-EL with sending
#3091
Conversation
Motivation: This closes apple#2754. It's a follow-up for apple#2753 that adds a way to `makeLoopBoundBox` by sendin a value, leaning into Swift 6 concurrency! Modifications: - Adds `makeBoxSendingValue`. Can't take the credit, @weissi wrote it in the issue. - Adds a test for it. Result: Nice NIOLoopBoundBox API for Swift 6.
| @@ -17,7 +17,7 @@ | |||
| /// | |||
| /// ``NIOLoopBound`` is useful to transport a value of a non-`Sendable` type that needs to go from one place in | |||
| /// your code to another where you (but not the compiler) know is on one and the same ``EventLoop``. Usually this | |||
| /// involves `@Sendable` closures. This type is safe because it verifies (using ``EventLoop/preconditionInEventLoop(file:line:)-2fxvb``) | |||
| /// involves `@Sendable` or `sending` closures. This type is safe because it verifies (using ``EventLoop/preconditionInEventLoop(file:line:)-2fxvb``) | |||
There was a problem hiding this comment.
Unrelated, but thought this would be more precise.
There was a problem hiding this comment.
Related: should I add more explicit documentation outlining that there are a bunch of functions to make a NIOLoopBoundBox off the event loop called make*, and outline the use cases for them at a high level? Separate PR?
| as: Value.Type = Value.self, | ||
| eventLoop: EventLoop | ||
| ) -> NIOLoopBoundBox<Value> { | ||
| // Here, we -- possibly surprisingly -- do not precondition being on the EventLoop. This is okay for a few |
There was a problem hiding this comment.
The comment is a copy-pasta from the other off-EL initializers, but I think it's fair to keep this for consistency.
| @@ -75,6 +75,43 @@ final class NIOLoopBoundTests: XCTestCase { | |||
| ) | |||
| } | |||
|
|
|||
| #if compiler(>=6.0) | |||
| class NonSendableThingy { | |||
There was a problem hiding this comment.
Could be an overkill. Also, should I explicitly mark this fileprivate?
There was a problem hiding this comment.
I'm actually a bit nervous about merging this.
We have a number of places where our Sendable constraints can be relaxed to sending, but I don't think we should actually do that yet. Many projects that depend on NIO support multiple Swift versions, just as we do, and it makes life quite a bit harder when doing implementation to have the APIs be different between those Swift versions.
In some cases this is acceptable, but in this instance I'm inclined to suggest we should wait, and do this work when we drop all compilers below 6.0. That would be at the release of Swift 6.2 (presuming no new Swift language versions).
Motivation:
This closes #2754. It's a follow-up for #2753 that adds a way to
makeLoopBoundBoxby sending a value, leaning into Swift 6 concurrency!/cc @weissi and @FranzBusch.
Modifications:
makeBoxSendingValue. Can't take the credit, @weissi wrote it in the issue.Result:
Nice NIOLoopBoundBox API for Swift 6.