The other option is to use CurrentEventLoop and friends from #2228 which only call preconditionInEventLoop() once during initialisation.

The other option is to use CurrentEventLoop and friends from #2228 which only call preconditionInEventLoop() once during initialisation.

Yes, good to have multiple options.

It seems like NIOLoopBoundBox has internal init with an unchecked event loop already. And, NIOLoopBox conforms to @unchecked Sendable. To confirm:

• We're not talking about that @unchecked Sendable protocol.
• You suggest adding a version of init and value get and set that would still verify the same event loop, but with an assert, so they might blow up.
• If the approach below is what you mean, then in release mode, no preconditionInEventLoop() will be invoked. So if something else changes what event loop the code is running on between debug and release, the user might get in trouble. But that's on them, they've used the unchecked variant.

Something like:

// NIOLoopBound

@inlinable
public init(_ value: Value, uncheckedEventLoop: EventLoop) {
    eventLoop.assertInEventLoop()
    self._eventLoop = eventLoop
    self._value = value
}

@inlinable
public var uncheckedValue: Value {
    get {
        self._eventLoop.assertInEventLoop()
        return self._value
    }
    set {
        self._eventLoop.assertInEventLoop()
        self._value = newValue
    }
}

@dnadoba @weissi I've read the proposal in #2228, but I'm not yet experienced enough to quite grasp how I could use it to achieve a similar result.

If the approach above is useful, I'm happy to put this together. If not, let me go work through a few example apps to gain more experience with event loops. Pointers / speed runs towards that particular area are very welcome 🙃

@natikgadzhi yes, thanks, uncheckedValue is exactly what I had in mind.

Thank you swift 😊❤️ I 🍏🍎 m glad you are you. Swiftapple. 😊 Good I will look it over and add or git init if it is possible thanks