Strange Syntax / Mapping to Unchecked Sendable (from SpeechRecognizer example)

[michael-prosper]

      continuation.onTermination = {
        [
          speechRecognizer = UncheckedSendable(speechRecognizer),
          audioEngine = UncheckedSendable(audioEngine),
          recognitionTask = UncheckedSendable(recognitionTask)
        ]
        _ in

        _ = speechRecognizer
        audioEngine.wrappedValue?.stop()
        audioEngine.wrappedValue?.inputNode.removeTap(onBus: 0)
        recognitionTask.wrappedValue?.finish()
      }

A couple questions here as a Javascript developer:

1. I assume this onTermination closure is invoked upon termination of the continuation. I also read in the documentation that the square bracket syntax is "capturing" and reassigning those dependencies to UncheckedSendables. What's confusing me is why is there an additional _ in scoped dependencies before the closure block?

2. Why are we reassigning those dependencies to UncheckedSendables?

Thanks!

[stephencelis]

1. I assume this onTermination closure is invoked upon termination of the continuation. I also read in the documentation that the square bracket syntax is "capturing" and reassigning those dependencies to UncheckedSendables. What's confusing me is why is there an additional _ in scoped dependencies before the closure block?

This is because onTermination takes a Continuation as a parameter. We're not using it, though, so we ignore it with a _.

2. Why are we reassigning those dependencies to UncheckedSendables?

This example maybe goes above-and-beyond to prepare for Swift 6 (to the point of making the demo too complex, perhaps), but we use UncheckedSendable because Speech and other Apple APIs have not been audited for concurrency yet, and produce warnings when concurrency warnings are enabled (which they are in this project).

If you don't have concurrency warnings turned on, you can hold off on uses of UncheckedSendable for now.

[michael-prosper]

Thank you so much for taking the time to reply to even such menial questions as this one. You guys are awesome and I truly appreciate the help!

I'm currently working through the past, present, and future of concurrency videos. Are those the best place to learn about you and Brandon's feelings about departing from Combine? I'm trying to make the right learning investments and sort of following in your footsteps, so would love to know which videos you'd recommend watching to learn more on that decision to go with the new async style rather than FRP.

[stephencelis]

We do talk about the trade-offs of Combine vs. async/await a bit in those videos. In general we think if you can embrace async/await you will end up with easier-to-read code. That said, we still think there's a ton of value in learning reactive streams abstractions like Combine (and Rx/ReactiveSwift before it), and given SwiftUI's reliance on Combine you won't be able to completely avoid it 😄

[michael-prosper]

Awesome. I appreciate that tip.

In thinking about portability of domain knowledge, it seems like learning reactive functional paradigms certainly has the highest level of "transferability" across platforms & technologies, would you agree?

For example, if I wanted to port an application I built with the composable architecture to say, React, if that Swift TCA application still leaned on the "legacy (Combine)" framework, then would it be more straight forward to translate? Whereas if the Swift Application utilized newer Swift features such as AsyncStreams, one would have to have an intimate knowledge of generator functions in Javascript to yield values to the caller in the same way we yield them to a continuation.

This may feel a little off topic and please feel free to ignore if so - I've just been fascinated with the evolution of code from my early Android days of imperatively linking your XML with Java and doing your best and praying that you'd appropriately accounted for each state your application could find itself in. Know, seeing State->View paradigms evolve is fascinating and it feels like the industry is reaching a kind of standard (looking at Android Jetpack Compose (funnily naming is still difficult and overlaps), Flutter, React, React Native, SwiftUI and likely more I've never heard of.