is this protocol necessary? what's the benefit over just extending the concrete type directly?

It allows us to add the output signal on bothWorkflowHost andWorkflowHostingController by just extending the protocol in WorkflowReactiveSwift. This was a suggestion in Andrew's feedback.

ah gotcha (sorry i missed the existing convo). so the tradeoff here is adding a 'public' protocol to which we really only want 2 specific things to conform so that we don't need to makeWorkflow orWorkflowUI depend onReactiveSwift – is that right? mostly out of curiosity – is it possible to define the protocol withpackage visibility? that seems like it might be a slightly more accurate definition (assuming it works and integrates successfully into the monorepo).

Before I had extensions onWorkflowHost andWorkflowHostingController which required a new module just to put the extension onWorkflowHostingController since I could not put it inWorkflowReactiveSwift since it does not know aboutWorkflowUI. Andrew's idea was use a protocol and drop the extension inWorkflowReactiveSwift so we don't need to have an additional module and the reactive swift stuff stays inWorkflowReactiveSwift.
I can look into thepackage visibility to see if that is possible.

If I make the protocolpackage visibility then theoutput property can't be public:
Property cannot be declared public because its type uses a package type

ah, makes sense – thanks for checking. maybe just as a matter of hygiene we should make the protocol underscored (_WorkflowOutputPublisher) and add comments regarding its purpose, since it doesn't seem like it's actually intended to be 'really' public.

Sounds good.

Pushed up the added underscore.

slightly inclined to split the storage for the property vs the observer, since that will give us the most control over when the 'outside world' sees the update. e.g.

var rendering: Renderinglet renderingSubject = PassThroughSubject<Rendering, Never>()

any thoughts on that? i guess one thing that would be different is that the old way (and presumably using a CVS) would have some baked-in synchronization mechanism over the underlying value. in theory this stuff should be main-thread-only though.

We currently are using a ReactiveSwift MutableProperty which does have an internal lock. Yes CurrentValueSubject does have some baked in serialization mechanism albeit without Apple documentation on what that is. Since we can't enforce someone reading the rendering value on the main thread I'm inclined to use the CurrentValueSubject since it's about as close as we can get as a Combine version of what we have now.
If we split the storage for the property out we could always lock around getting/setting it so I'm not against doing that but I think CurrentValueSubject should work for how we are using it.

let's plan on testing this fairly thoroughly. i'm never certain what the exact lifetime semantics are for the ReactiveSwift stuff personally...

Agreed. This has been in use in the ReactiveSwift bridging module for a while.

ah gotcha (sorry i missed the existing convo). so the tradeoff here is adding a 'public' protocol to which we really only want 2 specific things to conform so that we don't need to makeWorkflow orWorkflowUI depend onReactiveSwift – is that right? mostly out of curiosity – is it possible to define the protocol withpackage visibility? that seems like it might be a slightly more accurate definition (assuming it works and integrates successfully into the monorepo).