How is this meant to relate to Combine? The announcement almost seems to imply that this is a successor to that framework.
4 Likes
I think that is partially a reasonable conclusion, as it is with many things it is more complicated than just that. For some of what Combine accomplished we found it is better suited as an interaction at a language layer. For example async functions are considerably more lightweight than Combine's Future where an async function achieves it more easily and more efficiently.
Other things about Combine are nearly spot on; like for example the concept of dealing with values over time. Concepts like map or filter allow for some really expressive code that can be easy to read and understand.
One big issue is that it is very difficult to make your own publishers/operators without composition and have them be safe. AsyncSequence on the other hand is in many cases very easy to get right since it is so tightly integrated with the design patterns that the compiler offers as support for concurrency and iteration.
We focused on some of the key players from Combine and the swift-algorithms package that would cover the common use cases or items that might be difficult to implement correctly. I think it is safe to say this is not yet at a "1.0 type completeness" so adding additional things that Combine does offer that are compelling additions are fair game. I don't think we should limit ourselves to making just a replication of Combine, instead I think we should consider what the language offers and take inspiration from what people really use/need and focus on those parts first.
24 Likes
I guess once [Pitch] Observation is approved and merged … and once swift-async-algorithms is feature-complete then we can make a SwiftUI app 100% without Combine.
I don’t know if it’s Apple’s vision but it seems so 
3 Likes